-
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
Optimize balance-related queries with a cache #2383
base: master
Are you sure you want to change the base?
Conversation
match event { | ||
Event::MessageImported(message) => message | ||
.update_balances(block_st_transaction, |balance: Cow<u64>, amount| { | ||
balance.saturating_add(amount) |
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 think I'm gonna change these operations to "checked". My understanding is that we'll not be producing events that could lead to overflow, but if something unexpected happen it's still worth to see an explicit error instead of the balance being calculated incorrectly.
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.
Good catch. Hmm, it can happen if anyone decide to create their own token with huge balances. I think the Amount
should be u128
.
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.
After I implemented this check, some of the integration tests started to fail, because they used some arbitrary transactions with arbitrary amounts and wallets.
I'll be fixing them to use the wallets available in the test environment. One such test is fixed here. @MitchTurner, can you have a look at this and see if this fix makes sense? If so, I'll apply this to other tests.
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.
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 changed the asset balance to be u128
, leaving the contract balance as is.
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.
Also, the amount of each asset is still u64
, only the total balance has been promoted to u128
. If we want to also upgrade the amount I'll do it in a follow-up PR.
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.
Follow-up issue created: #2428
@@ -110,7 +110,7 @@ impl ImportTable for Handler<OwnedMessageIds, Messages> { | |||
let events = group | |||
.into_iter() | |||
.map(|TableEntry { value, .. }| Cow::Owned(Event::MessageImported(value))); | |||
worker_service::process_executor_events(events, tx)?; | |||
worker_service::process_executor_events(events, tx, true)?; |
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]: Would be nice to use some named variable or have a comment describing why it is true
(the same for another true
below)
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.
Updated in 0b39319
&DatabaseMetadata::V2 { | ||
version: <OffChain as DatabaseDescription>::version(), | ||
height: Default::default(), | ||
indexation_availability: [(IndexationKind::Balances)] |
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.
It would be nice to have a way to force us(via compiler) to handle new variant of the IndexationKind
enum here.
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.
Updated here: 8f3e817
/// Coin balances per user and asset. | ||
CoinBalances = 23, | ||
/// Message balances per user. | ||
MessageBalances = 24, |
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 think having 2 tables for balance it is too much=D I think w can have just one table with some:
enum Balance {
V1 {
coins: Amount,
messages: Amount,
}
}
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.
The suggestion would require the "asset id" to be a part of the key, even if it is technically not needed for messages. That's why I decided to structure it in two separate columns.
Also, current solution would allow us to add more types of "amounts" in the future, without requiring V2
.
match event { | ||
Event::MessageImported(message) => message | ||
.update_balances(block_st_transaction, |balance: Cow<u64>, amount| { | ||
balance.saturating_add(amount) |
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.
Good catch. Hmm, it can happen if anyone decide to create their own token with huge balances. I think the Amount
should be u128
.
Linked Issues/PRs
Closes #1965
Description
worker_service: 607: Balances cache available: false
query::balance: 100: Querying balances without balances cache owner=53a9c6a...
V2
if genesis is missingworker_service: 607: Balances cache available: true
query::balance: 151: Querying balances using balances cache owner=53a9c6a...
Technical considerations:
V2
which now containsindexation_availability
. This is a set that holds the available indexations (currently onlyBalances
)CoinBalances
andMessageBalances
that keep the coin and message balances respectivelyMessageImported
,MessageConsumed
,CoinCreated
,CoinConsumed
balance()
andbalances()
queries use these databases to satisfy the queryChecklist
Before requesting review