Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature][Bug?] Keep table intact on config/schema removal #841

Open
exp-table opened this issue Apr 29, 2024 · 3 comments
Open

[Feature][Bug?] Keep table intact on config/schema removal #841

exp-table opened this issue Apr 29, 2024 · 3 comments

Comments

@exp-table
Copy link

Let's start with a specific example ;

You have one ponder that's polyvalent (you add/remove contracts and events regularly).
You only need events from block A to block B for contract X. Once it has done its job, you remove altgother the concerned code in index.ts, config.ts and schema.ts.
Relaunching ponder will result in the previously populated table to be removed entirely.

It would be nice to have an option in the config perhaps to choose to maintain the table.

@0xOlias
Copy link
Collaborator

0xOlias commented Apr 29, 2024

Hi, welcome and thanks for opening.

This pattern is somewhat orthogonal to the way Ponder works. Specifically, Ponder aims to be deterministic, reproducible, and fast enough such that we can avoid maintaining user state between hot reloads / redeployments.

Have you considered:

  • Rather than remove a contract from ponder.config.ts, set the endBlock field? Ponder will stop indexing the contract at that height.
  • Create multiple Ponder apps?

Keen to help - would be great to hear more details about your use case.

@exp-table
Copy link
Author

Our use case is essentially tracking on-chain actions from users, which validates "quests" we have with partnering projects.

We are also using supabase, so not railway's db system, so every I/O has a cost! Repopulating tables from scratch everytime ramps these up, and also confuse users sometime because we are using data from tables to display informations!

We have thought about having one ponder app per quest, but the issue is then the limitation on how many pools we are allowed on supabase and how many one ponder needs (default is 30).

Though I will admit this is a very particular use case, deviating from the essence of ponder!

@0xOlias
Copy link
Collaborator

0xOlias commented Jun 13, 2024

Thanks for sharing, this is very helpful context. Don't have an immediate solution, but we will keep this use case in mind moving forward.

I will note that we're about to ship a release that will significantly speed up reindexing speed when using a remote database. After this change, it might be fast enough that you can tolerate leaving all quests around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants