storage: split runtime events related accounts into a separate table #809
Conversation
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
6 times, most recently
from
c1d59fc to
4c81c25
Compare
analyzer/runtime/visitors.go
Outdated
| } | ||
| } | ||
| 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
There was a problem hiding this comment.
Actually I went with the per block unique event indexes number (regardless of type) since that was the most straightforward. This is also internal to the DB field, so the problem i mentioned above (in case we skip events) doesn't really matter.
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
3 times, most recently
from
a73a23e to
be7cc48
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
9 times, most recently
from
0afd708 to
69a761f
Compare
| @@ -344,7 +342,7 @@ func ExtractRound(blockHeader nodeapi.RuntimeBlockHeader, txrs []nodeapi.Runtime | |||
| } | |||
| // Set the 'Success' field to 'Pending' for deposits. This is because the outcome of the Deposit tx is only known in the next block. | |||
| blockTransactionData.Success = nil | |||
|
|
|||
| blockTransactionData.RelatedAccountAddresses[to] = struct{}{} | |||
There was a problem hiding this comment.
oh I see. so here for example there's additional logic used in arriving at the "to" address that we want to apply before adding the "to" address to the related accounts
although we lucked out here because the signers are elsewhere added to the related accounts set
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
from
69a761f to
5d7e7d6
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
2 times, most recently
from
a4b2c12 to
07b9678
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
from
07b9678 to
5ca8e62
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
2 times, most recently
from
5025423 to
139e84e
Compare
ptrus
force-pushed
the
ptrus/feature/events-related-accounts
branch
from
139e84e to
03f1332
Compare
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.