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: add filter abstraction #2880

Open
ThallesP opened this issue Apr 1, 2024 · 5 comments
Open

feature: add filter abstraction #2880

ThallesP opened this issue Apr 1, 2024 · 5 comments
Labels

Comments

@ThallesP
Copy link

ThallesP commented Apr 1, 2024

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:

await program.account.offer.all([{ memcmp: { offset: 32, bytes: "<..>" } }]);

it could look like this:

await program.account.offer.all([{ where: { authority: "Qz8smxc<..>" } }]); // well maybe not in this method to avoid breaking changes

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.

@acheroncrypto
Copy link
Collaborator

I support this feature.

We would also need to make a PR to Anchor Lang as the IDL doesn't tell us the size of each field currently.

We have functions to calculate the offset in TS library:

public static typeSize(

@ThallesP
Copy link
Author

ThallesP commented Apr 1, 2024

I support this feature.

We would also need to make a PR to Anchor Lang as the IDL doesn't tell us the size of each field currently.

We have functions to calculate the offset in TS library:

public static typeSize(

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

@ThallesP
Copy link
Author

ThallesP commented Apr 3, 2024

just to be sure, can we follow with the size embedded inside the IDL? @acheroncrypto

@acheroncrypto
Copy link
Collaborator

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.

@ThallesP
Copy link
Author

ThallesP commented Apr 4, 2024

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.
Imagine this account:

#[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 where filter and others not. We can probably do some workarounds but that will make the code more complicated than it should be IMO.

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

No branches or pull requests

2 participants