Skip to content
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

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

joel-u410
Copy link
Contributor

@joel-u410 joel-u410 commented Jul 19, 2024

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:
image

And corresponding balances view (which maintains the previous behavior of the balances table):
image

After a transaction occurs which updates the balance (note the id changes in the returned row in the balances view to reflect which balance is now the latest one):
image

@joel-u410
Copy link
Contributor Author

Good news -- anoma/namada#3530 was merged, so I suppose after the next namada SDK release, this can be updated / rebased and will no longer require a forked version.

@mateuszjasiuk
Copy link
Collaborator

@joel-u410 👋 Do you still need this? I think your PR to namada was merged some time ago

@joel-u410
Copy link
Contributor Author

@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!

@mateuszjasiuk
Copy link
Collaborator

@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!

@joel-u410
Copy link
Contributor Author

@mateuszjasiuk I've rebased this now + resolved conflicts on latest main -- should be ready to go! 🙏

I was not able to run cargo test locally (it gave errors about the test database not existing) -- is there something I'm missing there? (I used docker-compose-db.yml to run a local database and set DATABASE_URL_TEST to point to it).

Would like to make sure all tests are passing before this is merged.

@joel-u410
Copy link
Contributor Author

re: running cargo test -- I created a database namada-indexer-test and my DATABASE_URL_TEST points to it. I get errors like this:

    0: Failed to establish connection: connection to server at "0.0.0.0", port 5433 failed: FATAL:  database "namada-indexer-test/test_db_1535_21" does not exist
    1: connection to server at "0.0.0.0", port 5433 failed: FATAL:  database "namada-indexer-test/test_db_1535_21" does not exist

It seems like I'm missing something here where the tests are supposed to have a new database for each test run?

@mateuszjasiuk
Copy link
Collaborator

You can try this: DATABASE_URL_TEST=postgres://postgres:[email protected]:5433 cargo test I'm not sure why cargo test is not picking up env. I did not have time to check it out 😅

@joel-u410
Copy link
Contributor Author

joel-u410 commented Nov 22, 2024

ah, I see ... DATABASE_URL_TEST must not specify a database name. Thanks, that worked.

@joel-u410
Copy link
Contributor Author

ok, so there is one failing test on this branch. I'll update & make sure that's passing before marking this as ready.

@joel-u410 joel-u410 marked this pull request as ready for review November 25, 2024 20:31
@joel-u410
Copy link
Contributor Author

joel-u410 commented Nov 25, 2024

@mateuszjasiuk this is ready for review now. I updated the test test_insert_balance_with_conflicting_owners to be more correct, I think, based on making it more like test_insert_balance_with_conflicting_tokens -- actually inserting a new token. As it was written, it was actually just a duplicate of test_insert_balance_with_existing_balances_update.

I also added another test case to test the behavior when a different balance amount is inserted with the same owner, token, and height (the new balance in that case is ignored).

Copy link
Collaborator

@mateuszjasiuk mateuszjasiuk left a 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| {
Copy link
Collaborator

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
Copy link
Collaborator

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;
Copy link
Collaborator

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 :)

Copy link
Member

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()
Copy link
Collaborator

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 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants