Is there a db connect-pool for rust?

I want begin a new project, mongodb is the only office db driver for rust now, but The mongodb rust driver not async ? Is there a db connect-pool?

Hello! I’m one of the engineers who works on the Rust driver. You’re correct that the driver currently doesn’t have async support; we’re hard at work designing how we want to convert the internals of the driver to async, and we plan on releasing an async API alongside the sync one and (changing the sync one to wrap around that) in the coming months.

3 Likes

Hi , since deno is written in rust…will there be a official deno wrapper or driver in coming future…

We don’t currently have any plans to integrate the Rust driver with Deno. I haven’t heard anything about plans to make a Deno-specific driver either.

Does mongodb-driver async only support tokio and async-std ?
How to support new async runtime library?

We’re still in the process of implementing the async functionality in the driver, but the plan is to have built-in support for both tokio and async-std out of the box (with a feature flag to select which one to use). We don’t plan on adding support for specifying a custom runtime right now. Is there a specific runtime that you wanted to use with the driver other than tokio or async-std?

Now I use may : async-coroutine-runtime, if mongodb support it that’s perfect !

may has beautiful Features:

  • The stackful coroutine’s implementation is based on generator;
  • Support schedule on a configurable number of threads for multi-core systems;
  • Support coroutine’s version of a local storage (CLS);
  • Support efficient asynchronous network I/O;
  • Support efficient timer management;
  • Support standard synchronization primitives, a semaphore, an MPMC channel, etc;
  • Support cancellation of coroutines;
  • Support graceful panic handling that will not affect other coroutines;
  • Support scoped coroutine creation;
  • Support general selection for all the coroutine’s API;
  • All the coroutine’s API are compatible with the standard library semantics;
  • All the coroutine’s API can be safely called in multi-threaded context;
  • Both stable, beta, and nightly channels are supported;
  • Both x86_64 GNU/Linux, x86_64 Windows, x86_64 Mac OS are supported

Right now, we’re pretty focused on finishing async support for the runtimes we’re already committed to supporting and then implementing the remaining features we consider necessary for our 1.0 release. Once we’re past 1.0, we can look into whether it’s worth adding support for custom runtimes.

1 Like