feature: add filter abstraction

[ThallesP]

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]

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:

https://github.com/coral-xyz/anchor/blob/475c69435584a1137441b827161b9b20055ee2c3/ts/packages/anchor/src/coder/borsh/idl.ts#L243

[ThallesP]

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:

https://github.com/coral-xyz/anchor/blob/475c69435584a1137441b827161b9b20055ee2c3/ts/packages/anchor/src/coder/borsh/idl.ts#L243

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]

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

[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.

[ThallesP]

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.

[melanke]

Just a feedback:

I am learning Solana for the first time, coming from other blockchains, and this is the one thing that makes me feel unconfortable with Solana.

Is there a workaround?

Anyways, I highly support this feature.