-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring of the graphql-api
service to use ports for Database
#858
Conversation
Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
51311f3
to
1b0b321
Compare
- Renamed `Transactional` into `Transaction`. - Added `Transactional` trait with `transaction` method. - Used `BlockId` instead of `Bytes32` in `Database`. - Created ports for `block.rs`, `tx.rs`, `message.rs`, `balance.rs`, `coin.rs` and updated corresponding schema. - Added and used in ports `BoxedIter` instead of associated types(In most cases they were `Box<dyn>` too). - Almost removed usage of fuel_core::database from schema. Only `dap.rs` uses it right now for `VMDatabase`. - Introduced `CompressedCoin` and `Coin`(contains `UtxoId`). `CompressedCoin` is used during work with the database, `Coin` in external API. - Moved resources into `fuel-core-type` and simplified it by removing generics. - Tried to re-work `dap.rs` but the change is big and also related to `fuel-core-executor`, so will do it in a separate PR. - Updated `Transactional` to support `Transactional<dyn Database>` Co-authored-by: ControlCplusControlV <44706811+ControlCplusControlV@users.noreply.github.com>
This is getting to be a very large PR, what's left todo on it? It may be good to work on getting this merged before more refactoring. |
It is in the stage when almost all work with |
.transaction_status(&transaction_id) | ||
.into_api_result::<TransactionStatus, StorageError>()? | ||
{ | ||
Some(TransactionStatus::Success { block_id, .. }) => block_id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to highlight that here I changed the business logic, now we don't allow verification for failed transactions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably ok since messages are only set by the VM currently. However there's nothing specifically preventing failed scripts from having a valid message output in the future.
graphql-api
service to use ports for Database
I have changes fixing the |
PR should be good for review now that dap is separated out and instances of |
|
||
/// The database port expected by GraphQL API service. | ||
#[cfg(test)] | ||
pub trait DatabasePort: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] why not just define a trait extension in tests?
crates/fuel-core/src/schema/chain.rs
Outdated
let query = BlockQueryContext(ctx.data_unchecked()); | ||
|
||
let latest_block = query.latest_block()?.into(); | ||
Ok(latest_block) | ||
} | ||
|
||
async fn base_chain_height(&self) -> U64 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just realized we forgot to update this api after finishing the relayer
Implemented base chain height. Removed duplication of `DatabasePort` for tests.
ca3ee34
to
af0aebd
Compare
@@ -21,7 +21,7 @@ use fuel_core_types::{ | |||
|
|||
#[async_trait::async_trait] | |||
impl RelayerDb for Database { | |||
async fn insert_message( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
Refs #809
Closes: #907
It is the refactoring for the
graphql-api
service to use ports instead of direct work withDatabase
. The service defines minimal database functionality and builds its functionality on top of it to process GrapQL requests.Right now, this functionality is represented by
{}QueryContext
structures with the public methods. It is done to make the migration easier.But later, we will need to move this functionality into corresponding traits and implement it directly for the
DatabaseTemp
type. Like:With traits, we can mock them and improve our tests.
The PR contains the following changes:
Transactional
intoTransaction
.Transactional
trait withtransaction
method.BlockId
instead ofBytes32
inDatabase
.block.rs
,tx.rs
,message.rs
,balance.rs
,coin.rs
and updated corresponding schema.BoxedIter
instead of associated types(In most cases they wereBox<dyn>
too).dap.rs
uses it right now forVMDatabase
.CompressedCoin
andCoin
(containsUtxoId
).CompressedCoin
is used during work with the database,Coin
in external API.fuel-core-type
and simplified it by removing generics.dap.rs
but the change is big and also related tofuel-core-executor
, so will do it in a separate PR.Transactional
to supportTransactional<dyn Database>
Before we can extract
grapgql-api
into its crate, we need:fuel-core-storage
.DatabaseVM
(The solution should also fit forfuel-core-executor
).