-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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: add filter abstraction #2880
Comments
I support this feature.
We have functions to calculate the offset in TS library:
|
The problem is that strings are length variable so we can't use that, the only way i see is to embed the size in the IDL |
just to be sure, can we follow with the size embedded inside the IDL? @acheroncrypto |
Adding a size field for unsized types doesn't make much sense to me. Instead, this should be handled in client side for the data types that we can reliably calculate. |
The problem is that if the account contains any string we can't reliably calculate the offset. #[account]
pub struct User {
pub name: String, // unknown offset
pub description: String, // unknown offset
pub likes: u8, // unknown offset because of previous strings
} That might confuse the user because some accounts shows the |
Currently, if we gotta do any filtering by field, we gotta manually crunch the offset of each field and then slot in the right bytes in order.
My suggestion is to improve the filtering to a simple field-value filtering.
So rather than this:
it could look like this:
We score type safety from this.
We make it simpler to use.
We would also need to make a PR to Anchor Lang as the IDL doesn't tell us the size of each field currently.
I'd be more than happy to make a PR and implement this.
The text was updated successfully, but these errors were encountered: