Raw Tables
Based on the Cosmos SDK schema every chain will have the following raw tables. They are marked with the dotted icon and contain more details in the description about how they are partitioned and clustered. Partitions and clusters are important to optimizing your queries so please refer to this section on how to optimize your queries.
Update frequency: real-time
Evmos has additional raw tables for EVM data
- transactions
- blocks
- event_atributes
- message_event_attributes
Here are some screenshots of the columns so that you understand how these tables map to a specific transaction:
- Transactions: contain high-level data about the transaction itself
- Blocks: high-level information about each block, its timestamp, proposer, and more.
- message_event_attributes: this table contains all events related to a message. As you might already know, Cosmos transactions can have more than one message per transaction. This table contains all events and their corresponding attributes that are triggered by state changes of that message. For reference here is a txn from Mintscan where you can see a txn from Mintscan, where you can see how events are emitted once in the
logsfield. As you can see in the screenshot, there are 2 different messages emitted in this txn and so are their corresponding events:
The table message_events_attributes displays solely events related to events and their correpsonding tx_id.
In Numia, you can use the column message_index to retrieve events from one or the other messages from the same transaction.
- event_attributes: this table contains all relevant events related to a transaction. This includes message_events from the
message_event_attributestable but mapped sequentially to the transaction, not the message. This is important because imagine you have a transfer event from 2 different messages on the first transaction, the SDK won't necessarily tell us in this table what message it belongs to. In the screenshot below you can see that events are indexed and ordered differently thanmessage_event_attribtues. Again, events are relative to txns and message_events are relative to messages. This includes all events from messages and also tx events of typetxthat are not related to messages.
In general, we recommend using
message_event_attributes this as this table is smaller and will lead to lower amounts of data being queried. Otherwise, refer to the following questions to decide:Use
message_event_attributes when:- You are analyzing multiple messages in the same transaction
- You have multiple events of the same type in the same transaction emitted by different messages
Use event_attributes when:
- You need data about failed txns, since failed txns don't emit message_events, only txn events
- You need to retrieve the transaction signer via
event_type = txnandattribute_key = acc_seq
Last modified 9d ago