request to adding database support for mongodb 0.9.0

[phantomxe]

Mongodb officially released the rust driver.

[TheBestJohn]

Deadpool will be able to do this for you I believe. Take a look at this post: https://www.reddit.com/r/rust/comments/e9n6mx/creating_and_using_a_postgres_database_pool_is/

Deadpool basically sets up an async pool for any connection to data. This example uses Postgres but the setup looks almost identical to MongoDB.

Looking more into Deadpool, You may need to implement the Manager trait on a mongodb but I imagine doing that wouldn't be too much work if you base it off the deadpool-postgres crate.

[jebrosen]

This can be updated once r2d2-mongodb is updated, but it won't land until 0.5.

mongodb is synchronous, so r2d2 is probably a better choice than deadpool if you need to use it now. This can be done with a manually managed pool, as described in https://rocket.rs/v0.3/guide/state/#databases.

[Figments]

The official driver includes its own database pooling support. Is R2D2 still required to make official support possible?

To add on from one of the official driver developers:

Note that wrapping this driver with r2d2 is probably not a good idea; it implements connection pooling under the hood, following the MongoDB CMAP spec. This means that making an r2d2 pool of Client (and by extension, of Database or Collection) will create a connection pool for each one, as well as all of the background threads that the driver needs for not only the pools but also to monitor the topology. The Client type implements Clone and Send, meaning that the best way to use it is to create one and then make a copy for each thread you spawn.

mongodb/mongo-rust-driver#109 (comment)

[jebrosen]

I did not see that the new client has pool support built-in; thanks for mentioning that. The current database support (#[database]) is built on r2d2 and I don't think it would be very easy to change - definitely not in 0.4.

Since one of the main benefits of #[database] is the connection pooling, it probably makes more sense (at least for now) to put a mongodb Client in managed state yourself, optionally with a request guard (i.e. the 0.3 database example).

[Figments]

It might, then, be beneficial to include MongoDB-specific documentation in the interim in case moving away from R2D2 in the far future is possible. That way anyone that wants to use Rocket with the officially-supported driver doesn't have to dig all that far to find out how (as documentation for manually-managed database state is currently buried in an older version of the documentation, and is non-obvious unless you dig around and/or find this issue thread).

I can try to write something after I figure out how to implement it, if that's alright.

[jebrosen]

I do think we should inline and/or link to the 0.3 database documentation, for the case of an unsupported database engine or different version (see also #1179).

MongoDB is a bit different now by having its own connection pool: it can be used just as any other managed state via State<'_, Client>. Creating a custom connection guard is optional and beneficial mostly in the case of connecting to multiple mongodb servers.

[jebrosen]

Update: #1378 removed the mongodb integration, since the newest version 1) is async and 2) does its own connection pooling. I still want to work on / extend #866 or a similar example of mongodb usage implementing the approach in my last comment. It would also be really nice to support mongodb as part of #1117 in some way, using mongodb's own connection pooling automatically.

[SergioBenitez]

Let's track this in #1117.