#Query Vec of Foo via only some fields of Foo?

35 messages · Page 1 of 1 (latest)

marble jay
#

I'm in the very early process of writing a simple database (somewhat similar to mongodb) and I'm thinking about how I should implement a query to the database in a typed language like Rust.

I want to have Collection<T> that contains Vec<T> where T is a document. In order to get a mutable reference to change T I would need to query Vec<T> by only certain fields of T if that makes sense. Should I do this with a derive macro?

I would like to do something like this:

struct Collection<T> {
  inner: Vec<T>
}

impl<T: Query> Collection<T> {
  pub fn query(&mut self, q: impl Query) -> Vec<&mut T> {
    // ????
  }
}

#[derive(Query)]
struct Foo {
  bar: String,
  baz: String,
  zig: String,
}

// then I might try:
let query = Foo {
  bar: "something something".to_string(),
  ..Something::something(),
};

// res only has Foo in collection's inner Vec<Foo> that matches query.bar:
let res: Vec<Foo> = collection.query(query);

Is this the best way to do a query without all the fields filled? If this isn't possible should I just try to serialize it to json and do queries by json strings? (that would be slow and complicated, though the data will actually already be stored as json on the web backend)

pine geyser
#

If you want a variable to be optional, you should wrap the type you want in an Option<T>, to allow it to be either a Some or None variant.

marble jay
pine geyser
#

I thought this question was relating to the struct for specifying queries, not a struct being serialised...

marble jay
#

I'm not sure what you mean?

pine geyser
#

Is this the best way to do a query without all the fields filled?
From that question, and the structure of the snippet, I got the impression your post was about how to specify the implementation for structs for specifying queries, not data which was going to be serialised and stored in the database...

marble jay
pine geyser
#

What crate are you using for interfacing with this database?

#

If any.

marble jay
#

Maybe I should have been more specific about what I'm actually doing. I'm trying to write a database wrapper for github so you can use it as a database similar to mongodb. I'd be making HTTP calls to github's api on every database read/write.

#

So it's not an actual database, it's more just a filesystem that I'm reading/writing to (in json so it's human readable). I'd like to create an api to interact with it like you would with something like mongodb.

#

So in the query fn I would:

  1. Download the JSON from github (easy)
  2. Parse as Vec<T> (easy)
  3. Get back Vec<T> from Vec<T> where certain fields of T match the query. (hard)
#

Maybe I should have been more concise in my original question. most simply, I'm trying to get all occurrences of T in Vec<T> where only certain fields match a query.

#

I'm not sure if I'm making much sense, does that make sense? @pine geyser

pine geyser
#

Probably the easiest option for that, would be up use the filter iterator adaptor...

marble jay
pine geyser
#

That would be fine, assuming proving read access to the elements is reasonable.

#

For the scope of the closure, that is...

marble jay
#

Hmmm

#

Okay I think I'll try passing in a filter to query, I think that's the simplest option, yeah

pine geyser
#

Is there a reason beyond this for encapsulating the Vec as a newtype?

marble jay
#

Why am I creating Collection<T> when it only contains Vec<T>?

#

Well it will contain more things like the URL, HTTP request client, credentials, etc.

pine geyser
#

Ok, that makes sense in that case.

marble jay
#

And methods that abstract over the "low level" operations of interacting with github like a database such as caching, querying, updating, etc.

#

The point of the library would be to make a wrapper to interact with github as a database easily as if you were using mongodb or a similar document based database.

pine geyser
#

Is that allowed by GitHub ToS...?

marble jay
#

I haven't checked

#

hmmm maybe I should check haha

marble jay
#

Plus I'm not sure why they'd include editing repository files in their rest api if not for automated usage

pine geyser
#

Yeah, I'd assume they don't intend for it to be used as someone else's production database though,

marble jay
#

Oh yeah it's definitely not a good idea to use it as a production database