-
Notifications
You must be signed in to change notification settings - Fork 8
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
[enhancement] store balances at block heights - implementation #81
base: main
Are you sure you want to change the base?
Conversation
0bb5d21
to
e60b7ba
Compare
e60b7ba
to
fc01750
Compare
Good news -- anoma/namada#3530 was merged, so I suppose after the next |
@joel-u410 👋 Do you still need this? I think your PR to namada was merged some time ago |
Hi @mateuszjasiuk yes I'd still like this change to get merged (though it is out of date and needs some work now!) I just haven't had the chance to come back to this project yet (have been waiting until closer to mainnet launch to refocus here). Please keep it open, if it's not too much trouble, and I will update/rebase this soon (probably next week) based on the current namada SDK which does have my PR merged now. Thanks! |
Sure, no problem! |
… wrapper_transactions
This reverts commit b6aa705.
2b76c49
to
15dd4fa
Compare
@mateuszjasiuk I've rebased this now + resolved conflicts on latest I was not able to run Would like to make sure all tests are passing before this is merged. |
re: running
It seems like I'm missing something here where the tests are supposed to have a new database for each test run? |
You can try this: |
ah, I see ... |
ok, so there is one failing test on this branch. I'll update & make sure that's passing before marking this as ready. |
…at the same height
@mateuszjasiuk this is ready for review now. I updated the test I also added another test case to test the behavior when a different balance amount is inserted with the same |
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.
Tested and I think this looks great. Left couple of comments for discussion, but in general awesome work!
EDIT: also my small concern is that up until this point we would just store current state, so if someone starts indexing late then the balance changes will start at block x not first one. If we provide new endpoint to get balance at height we probably need to mention this in the description
tracing::info!("Inserting {} balances into db", balances.len()); | ||
|
||
// Group balances into chunks to avoid hitting the limit of the number of bind parameters in one query. | ||
balances.chunks(10000).try_for_each(|balances_chunk| { |
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'm not sure if it fits your usecase but we also have insert_balance_in_chunks
right below this function
}; | ||
|
||
db.run_test(move |conn| { | ||
seed_balance(conn, vec![balance.clone()])?; | ||
|
||
// TODO: this is probably not a valid way to construct an IbcToken |
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 it's fine to remove TODO but leave comment
OWNER, | ||
token) max_heights ON bc.owner = max_heights.owner | ||
AND bc.token = max_heights.token | ||
AND bc.height = max_heights.max_height; |
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.
We do breaking changes all the time before mainnet launch, so you can also just change init_balances
migration if you like to simplify the 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.
agree, if you could avoid having the migration and modify directly the balance table would be great! can keep the view, thanks!
@@ -18,6 +18,7 @@ pub fn insert_inner_transactions( | |||
.map(InnerTransactionInsertDb::from) | |||
.collect::<Vec<_>>(), | |||
) | |||
.on_conflict_do_nothing() |
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.
Can you give some context why this is needed, I think conflict should never happen 🤔
Pushing this as draft, in order to show my proposed changes here. This cannot be merged until the corresponding feature is merged in the SDK: anoma/namada#3530. After that's done, I'll come back here and update this to use the upstream SDK and not my fork.
This implements #77.
Example of the
balance_changes
table:And corresponding
balances
view (which maintains the previous behavior of thebalances
table):After a transaction occurs which updates the balance (note the
id
changes in the returned row in thebalances
view to reflect which balance is now the latest one):