-
Notifications
You must be signed in to change notification settings - Fork 0
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
Supporting parsed data #5
Comments
are you looking at this to have preprocesses (pre-parsed) data or to parser on query? pre-parsed:
|
could you clarify - we need it parse account data as well as instructions? @linuskendall |
Referencing this thread here - https://x.com/redacted_noah/status/1723031204180398374?s=20 Using runtime parsing would probably work for such a usecase, but we could also consider a separate table, or additional field for JSON data if we wanted to make use of DB to seek over specific values in a JSON from IDL. Obv scanning over rows in mem would be nasty for large scans |
IMO any parsing that ends up in a data store should be based on IDL, then you eliminate the two CON's Anything additional should be computed on query |
There are a few corners of the current RPC spec that requires knowledge about onchain programs and the ability to interpret them (or rely on some kind of indexed data store) - in particular to support the jsonParsed encoding.
There has also been requests from developers for having higher level interfaces for both filter (getPA style) and for getting more parsed account data (a la jsonParsed). Currently
jsonParsed
supports only a limited set of programs (https://github.com/solana-labs/solana/tree/master/transaction-status/src) and has no easy way to extend.Suggestions that have been floated:
The text was updated successfully, but these errors were encountered: