-
Notifications
You must be signed in to change notification settings - Fork 4
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
Create a seperate table for storing logs. #102
Conversation
4c43c21
to
fdedb5f
Compare
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.
Need to make some changes to the db schema, which will necessitate updating the go code some too, but otherwise everything looks great (and would work for the current schema).
topic0s VARCHAR(66)[], | ||
topic1s VARCHAR(66)[], | ||
topic2s VARCHAR(66)[], | ||
topic3s VARCHAR(66)[], |
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.
Don't we need another column for data
?
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.
Done
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.
Didn't see this til after commenting: #102 (comment)
If you think it is useful from a users/consumers perspective let's do it @ashwinphatak
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 useful if we implement the GetLogs GQL API using the log index table in cerc-io/ipld-eth-server#92, so we don't have to read it from elsewhere?
We haven't done that yet in the linked PR in ipld-eth-server. We should return the log CID and ipld block there, maybe also the receipt CID in a new field.
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-norden While doing this, would it make sense to filter out "failed" logs (based on the receipt status) here: https://github.com/vulcanize/ipld-eth-server/blob/master/pkg/graphql/graphql.go#L1031 (or in the table join, as long as the log index turns out correct)
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, just one or two minor tweaks and then there are a few things still open to discussion. I'll bring these things up in slack and we can figure out what the best approach is.
log_data BYTEA, | ||
mh_key TEXT NOT NULL REFERENCES public.blocks (key) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, |
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.
So we still want a mh_key
and cid
that reference an IPLD block in this table, but instead of referencing a Log IPLD it should reference a LogTrie leaf node IPLD (the leaf node that contains the log this table was previously directly referencing). Does that make sense? It will be a bit involved/tricky to generate this cid/mh_key, you'll probably need to iterate over the trie we generate in processLogs
while noting the path of each leaf node (the path is the RLP encoding of the log's index in the Receipt.Logs list, so we can tell which log is in which leaf based on the leaf node's path and the known index of the log).
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.
Done
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.
Thanks Arijit, this is looking good. A few comments, nothing major. But I'm curious if we have proper unit test coverage for the indexing of the logs table- tests that include the new mh_key
and cid
rows? I don't see it in this diff, might have missed it.
statediff/indexer/indexer.go
Outdated
} | ||
logMhKey[idx] = mhKey | ||
logCID[idx] = 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.
Do we need to reallocate the log CIDs to this new logCID slice, can't we use the slice in args.logLeafNodeCIDs?
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.
Done
@@ -1,6 +1,8 @@ | |||
-- +goose Up | |||
CREATE TABLE eth.log_cids ( | |||
id SERIAL PRIMARY KEY, | |||
cid TEXT NOT NULL, |
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 we should rename this to leaf_cid
, to make it clear our CID no longer references a log directly but rather the leaf node that contains it. What are your thoughts on that @ashwinphatak?
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.
Yes, makes sense.
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.
Done
@@ -1,6 +1,8 @@ | |||
-- +goose Up | |||
CREATE TABLE eth.log_cids ( | |||
id SERIAL PRIMARY KEY, | |||
cid TEXT NOT NULL, | |||
mh_key TEXT NOT NULL REFERENCES public.blocks (key) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED, |
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.
And same here, we could rename this to leaf_mh_key
to make an explicit distinction.
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.
Done
statediff/indexer/indexer.go
Outdated
mappedContracts[l.Address.String()] = true | ||
logDataSet[idx] = &models.LogsModel{ | ||
ID: 0, | ||
Address: l.Address.String(), | ||
Index: int64(l.Index), | ||
Data: l.Data, | ||
CID: logCID[idx], |
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.
Related to #102 (comment), couldn't this be args.logLeafNodeCIDs[i][idx]
?
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.
Done
Will merge this PR once we have a major release #107 |
09e4dae
to
921242a
Compare
No description provided.