Updated dependencies, rewritten code utilizing mongodb::IndexModel

[styrowolf]

I have updated dependencies and rewritten the code to utilize mongodb::IndexModel instead of wither::IndexModel, which is just a placeholder. The tests have been updated and is passing too.

[thedodd]

Thanks for tackling this work! Just a few items that caught my eye. Keep me posted.

[thedodd]

I'd prefer not to use unwrap at all. No way to just use a doc!{} here in the .options(...) bit? If not, then we should likely use an intermediate type to hide this complexity, but which will results in the correct MongoDB IndexModel. Thoughts?

[styrowolf]

.options(...) takes IndexOptions as a parameter, so I don't think there is a straightforward way to use a doc!{} there.

Preferably, we should have the macro abort with an error if deserializing the doc!{} to IndexOptions does not work. However, I cannot think of a way (not very knowledgeable about macros) to do that, as that would require executing the from_document(...) function at compile-time.

Another solution would be to change the #options tokens to some expression that returns a IndexOptions instead of doc!{}. But that means changing the public API. For comparison,

The old way of defining options is:

// Define a model. Simple as deriving a few traits.
#[derive(Debug, Model, Serialize, Deserialize)]
#[model(index(keys = r#"doc!{"email": 1}"#, options = r#"doc!{"unique": true}"#))]
struct User {
    /// The ID of the model.
    #[serde(rename = "_id", skip_serializing_if = "Option::is_none")]
    pub id: Option<ObjectId>,
    /// The user's email address.
    pub email: String,
}

The new way would be:

// Define a model. Simple as deriving a few traits.
#[derive(Debug, Model, Serialize, Deserialize)]
#[model(index(keys = r#"doc!{"email": 1}"#, options = r#"IndexOptions::builder().unique(true).build()"#))]
struct User {
    /// The ID of the model.
    #[serde(rename = "_id", skip_serializing_if = "Option::is_none")]
    pub id: Option<ObjectId>,
    /// The user's email address.
    pub email: String,
}

Please let me know your thoughts on this.

[thedodd]

Oh nice ... that is not a bad idea at all. Path of least resistance, perhaps. I think that is worth experimentation. As long as none of the tests fail and can be effectively adapted, then I would say that we have a clean win, and it will effortlessly stay up-to-date with upstream changes in the driver.

Good call. Keep me posted! Sorry for the late response :)