Manually getting connection from pool: why?

[georgeboot]

I initially used SeaORM but can't live with it's quirks. I now discovered diesel (async) and its amzing!

One thing I noticed that when using a connection pool (we use bb8), it's up to the developer to check out a connection from the pool.

Why is this? In my code, I find myself getting a connection, running a query and releasing it again, over and over again.
In seaorm, I would give a ref to my connection pool, and Seaorm would take the connection for me. This also means I dont have to worry about holding a lock on a connection for longer than needed.

Was this designed like so on purpose?

[weiznich]

There are several reasons of this design:
The first and most important reason is that this design is what we started with back then in the beginning days of diesel. Changing it would break existing code, so we avoid that for things that are not clearly better.
The next reason is that this design gives you much greater control over which connection is used for what. For example things like pipelining would be otherwise much harder to implement and to use. I personally feel that having to pull out a connection manually makes you more aware about when you use connections for something and prevents issues with using e.g multiple connections at the same time for the same request.
Finally I guess such a design would require use redesign how our transactions work, which again would break a lot of code and likely again loose control about details.

---

Now I don't know your code base but assuming that it is the "usual" web server setup you can consider to just have a custom extractor via your web server framework and just pull out the connection from the pool via by having it as function argument.

[georgeboot]

Ah thank you for the detailed answer!

In theory it should be possible to swap out Conn for something like impl IntoConn, right? Don't know how to handle pool errors though.

This would give flexibility of using both wherever you want.