add event logs to stf and db #409
Conversation
ecioppettini
force-pushed
the
enzo/add-event-logs-to-stf-and-db
branch
2 times, most recently
from
9f913ac
to
b569c27
Compare
ecioppettini
force-pushed
the
enzo/add-event-logs-to-stf-and-db
branch
from
635f2ba
to
6d815f5
Compare
Co-authored-by: Sebastien Guillemot <SebastienGllmt@gmail.com>
| eventDescriptions: { topic: string; fieldName: string; indexed: boolean }[] | ||
| ): Promise<boolean> { | ||
| for (const event of eventDescriptions) { | ||
| const indexName = `index_${event.topic.slice(0, 20)}_${event.fieldName}`; |
There was a problem hiding this comment.
TODO: document this in the docs (one index per field)
| @@ -753,6 +753,61 @@ const TABLE_DATA_CDE_DYNAMIC_PRIMITIVE_CONFIG: TableData = { | |||
| creationQuery: QUERY_CREATE_TABLE_CDE_DYNAMIC_PRIMITIVE_CONFIG, | |||
| }; | |||
|
|
|||
| const QUERY_CREATE_TABLE_EVENT = ` | |||
| CREATE TABLE event ( | |||
| id SERIAL PRIMARY KEY, | |||
There was a problem hiding this comment.
We shouldn't use serial fields here. The STF will eventually process inputs in parallel, making the order non-deterministic
There was a problem hiding this comment.
I can probably change the pk to block height + index inside the block instead, but I'm not sure it would make any difference. Can you explain what does it mean to process inputs in parallel? Because even then you could call the stf multiple times in parallel and then serialize the results.
There was a problem hiding this comment.
I think having the ID be deterministic even in the case where transactions are executed in parallel is equivalent to the other open discussion on this PR: #409 (comment)
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| data: { [fieldName: string]: any }; | ||
| tx: number; | ||
| idx: number; |
There was a problem hiding this comment.
It's probably not clear from the name that this is meant to represent the order in which this log was executed within the transaction
There was a problem hiding this comment.
I renamed it to logIndex. Only caveat is that if we wrap this to implement eth_getLogs, we need to remember that this is the index of the log in the tx, and the other one is the index of the log in the block. I guess we may be able to compute the index of the log out of the tx index and the log index though?
There was a problem hiding this comment.
Or maybe we may want to change this field to be the log index in the block to be consistent with that? I just used the index in the tx because it's what was described in #373
There was a problem hiding this comment.
ah good catch. I feel it should probably by the index in the block instead of in the transaction then
Implements parts of #390
There some missing parts still though: