Feature request: Support "queriable" fields

[Raj2032]

Say I have this struct:

#[derive(Serialize, Deserialize, PartialEq, Debug)]
#[native_model(id = 1, version = 1)]
#[native_db]
struct Customer
{
    #[primary_key]
    id: u16,
    name: String,
    age: u8,
    is_active: bool,
}

Issue is that if I wanted to search for the customer's name, it would be much slower as we have to go through every row, deserialize it and then determine if the customer's name is "John" for example.

I could use a #[secondary_key] however the issue over here is that what if there are two rows that has the same customer name.

I wanted to suggest something like #[queryable] or something like that in this example:

#[derive(Serialize, Deserialize, PartialEq, Debug)]
#[native_model(id = 1, version = 1)]
#[native_db]
struct Customer
{
    #[primary_key]
    id: u16,
    #[queryable]
    name: String,
    age: u8,
    is_active: bool,
}

fn main()
{
    for item in r.scan().queryable::<Customer>(ItemKey::name)?.start_with("John") {
        println!("{}", item);
    }
}

something like this. More over to support nested structures:

struct Customer
{
    id: u16,
    name: Name,
    age: u8,
    is_active: bool,
}

struct Name
{
    first: String,
    last: String,
}

[vincent-herlemont]

I could use a #[secondary_key] however the issue over here is that what if there are two rows that has the same customer name.

@Raj2032 That should not be a problem, because the secondary_key is not unique by default (Could you provide more details about your original code/problem?). Thus, you can retrieve multiple entities by performing a scan of the secondary keys, see here.

[Raj2032]

That should not be a problem, because the secondary_key is not unique by default

My mistake, I was under the impression that secondary key is also unique, I checked out the docs and yeah makes sense.

Its a very interesting project and it looks like this might be the database I have been looking for, most other databases out there require you to type everything as a string when doing queries, other issues it doesn't integrate with Rust very well, data types are different to Rust. So yeah I am quite happy this is most likely the most appropriate database to use.

Will be closing this issue now.