search

near / near-indexer-for-explorer

Watch NEAR network and store all the data from NEAR blockchain to PostgreSQL database
https://near-indexers.io/docs/projects/near-indexer-for-explorer
GNU General Public License v3.0
123 stars 56 forks source link

Expose information about genesis records #106

Open frol opened 3 years ago

frol commented 3 years ago

Currently, we index genesis into the regular tables, but then it is hard to reason whether the data was initially included in the genesis.

For example, we store genesis accounts into accounts table with created_by_receipt_id set to NULL, but if later the account gets re-created (deleted and created once again), we lose that created_by_receipt_id IS NULL characteristic. Well, the same problem is applicable to all the re-creation events since we lose track of the previous create/delete checkpoints, so we do not represent the history correctly. One of the solutions is to have an extra table as we had access_keys in the indexer-for-wallet, where we recorded each add/delete event independently.

@khorolets How do you feel about having the "events" tables for accounts, access keys, and contracts (deploy contract / delete account)?

khorolets commented 3 years ago

I'm fine with that. What's the reasoning for that? Why we care if that were in genesis or recreated later? What's the use-case of such table in Explorer? I recall in indexer-for-wallet we did this way because we couldn't do other way. Later Wallet adopted Explorer's approach because it really cares on current state of things. Just wonder if it is necessary as we're going to bring a huge amount of data into that tables and I'd rather avoid it there's no specific use-case for that.

frol commented 3 years ago

Thanks for bringing these conserns!

What's the reasoning for that?

On Explorer we want to display information about the genesis (how many accounts/contracts were there)

Why we care if that were in genesis or recreated later?

It is important to provide accurate stats. Currently, it does not introduce any issues, but this inaccuracy bothers me a bit.

What's the use-case of such table in Explorer?

It might be used for accurate time-travel and stats.

Just wonder if it is necessary as we're going to bring a huge amount of data into that tables and I'd rather avoid it there's no specific use-case for that.

I agree, which is why I believe this issue is going to be just a placeholder for future discussions. It is not sufficiently important right now, I believe.

The only thing that we have a hard time right now is answering how many contracts are there since we don't have contracts table at all and we can only use DeployContract actions to estimate, but it does not include cases when an account is deleted or contract was deployed in genesis.

khorolets commented 3 years ago

@frol IMO if we struggle with contracts related info let's focus on that and try to address it separately. In such way we can improve Indexer for Explorer step by step without bringing something unnecessary as the amount of data is big enough to cause problems.