-
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
v5 Checkpoint #233
v5 Checkpoint #233
Conversation
…or the separation of concerns was because we used to fetch cids directly from the database but then use those to fetch iplds using an ipfs.BlockService abstraction ontop of our database (and/or a ipfs.BlockExchange). But now they are both accessed directly in the local DB. Additionally, some of the queries should be further refined/refactored/combined as we no longer need to take two trips but can retrieve cid and ipld in the same query.
… over there in v5
This actually isn't so bad to review |
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.
LGTM as an incremental part of v5.
One revision - we can change the tag of the ipld-eth-db
migrations container to v5.0.0 in the docker-compose.yml
. It won't work until that tag is published, but it's not run on this branch anyway.
Merging this, next PR will have the test fixes |
This is the bulk of the functional updates. Not quite finished but getting close. Builds but still need to fix some (most) tests.
ipfs.BlockService
abstraction (which could be applied on-top of our DB, using ipfs-ethdb, or used on-top of an IPFS p2p block exchange. We now fetch everything from the local Postgres DB for performance reasons, in one trip where possible.eth_call
and relevant graphql endpoints.TODO: