storage: split runtime events related accounts into a separate table #809
Conversation
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
5 times, most recently
from
ba2ff6d to
c1d59fc
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
from
c1d59fc to
4c81c25
Compare
| return "", err | ||
| } | ||
|
|
||
| relatedAddresses[addr] = struct{}{} |
There was a problem hiding this comment.
what does these now
I see that these calls are replaced with the one that only notes the preimage in the tx, message, and event visitors
the tx related accounts are now populated by combining the related accounts from the tx's events. that might work. as long as it doesn't miss anything that only shows up in the tx
how do the events' related accounts get populated
| } | ||
| } | ||
| return nil | ||
| return currIdx, nil |
There was a problem hiding this comment.
This doesn't work ok with events that are currently not tracked and would be tracked in future. E.g. adding a handler for new event types would change the resulting indexes on reindex.
The index should probably be made out of 2 values (index within GetEventsRaw, and then the index within the "DecodedEvents").
There was a problem hiding this comment.
come to think of it, how do oasis-core and oasis-sdk architecturally represent events? I think they're put into a map[event_type]slice_of_events kind of structure per block or tx
There was a problem hiding this comment.
do we skip events?
Yeah for example rofl events are currently skipped (added in #812)
come to think of it, how do oasis-core and oasis-sdk architecturally represent events? I think they're put into a map[event_type]slice_of_events kind of structure per block or tx
Yeah that's how it is done in oasis-sdk. So maybe going with (event_type, index) pair would be the best to represent this in the db as well. (where index is the index within the events of the same type).
There was a problem hiding this comment.
that sounds ok. I hope using a text column in the key is not too expensive
Fixes: #804 #786
This splits
runtime_events.related_accountsinto a separate table, because otherwise we are unable to support efficient queries for event related accounts ordered by round. Some more context in #804Additionally, we need to introduce an event index (solves #786) because otherwise the new table cannot reference the existing
runtime_eventstable, which currently has no primary key, so rows cannot be referenced uniquely.Because of the event index change, we would need a reindex of the runtime events.
This is blocked on either:
gocode, which would reindex just the runtime events table)