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

Non-ObjectId _id fields #92

Open
loafofpiecrust opened this issue Jan 25, 2022 · 1 comment
Open

Non-ObjectId _id fields #92

loafofpiecrust opened this issue Jan 25, 2022 · 1 comment

Comments

@loafofpiecrust
Copy link

I recently started checking out this library but found a hurdle to my adoption: I want to use custom types in the _id field which serialize to a String. Would wither be able to support this, instead of strictly requiring id: Option<ObjectId>?

@aswinmurali-io
Copy link

If we have an option to use ObjectId as String like id: Option<String> that would be great!

This is my scenario. The prost crate supports converting .proto protobuf schemas to rust struct definitions. It will automatically convert protobuf schema types to rust types. The prost-build crate supports additional features to add custom derives in the generated rusts. I used it to derive the generated struct with serde::Serializable, serde::Deserizable & wither::Model. This way using the prost crate, from protobuf I get fully generated rust code that works directly with mongodb with the abstraction advantage of wither!! It's a dream come true when it comes to scalability & maintainability.

But there is one problem. Unlike all the basic std types I used in my protobuf schemas. The id attribute uses the wither::bson::oid::ObjectId type which does not implement the prost::Message trait need for deserializing protobuf data. Kinda makes sense because ObjectId is not a type that is supported by protobuf anyway. But the prost crate implemented String with the prost::Message trait since it's a basic type support in both rust and protobuf. Since ObjectId technically can be parsed from a String we should be able to make it work. But the wither::Model trait is forcing me to only use the exact Option<ObjectId>.

If there was a flag to support Option<String> it would finally bridge the gap between all the tech I use from

  • protobuf - fast binary data exchange format with schema support
  • prost - for generating rust struct from protobuf schema & deserializing them from protobuf data.
  • serde - general serializing & deserializing
  • mongo - my database of choice
  • wither - makes mongodb easier for me

If there is a monkey-patch solution please do let me know. I can fork wither and do the change until there is an official merge.

cc @thedodd

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

No branches or pull requests

2 participants