Remember the pool options for a given connection.

[sauvainr]

To use pooling the current usage is:

{:ok, conn} = Mongo.start_link(database: "test", pool: DBConnection.Poolboy)

Mongo.find(:mongo, "collection", %{}, limit: 20, pool: DBConnection.Poolboy)

Having to repeat pool: DBConnection.Poolboy at query time should not be necessary.

[ankhers]

This is a limitation of the db_connection package. It expects that we pass the database specific options for each query.

I have been toying with the idea of providing our own behaviour for DBConnection.Pool which would essentially just wrap a connection for the topology. Unfortunately I just have not gotten around to doing trying it yet.

[sauvainr]

How about using a global configuration?

Application could configure:
config/config.exs

config mongodb:
  pool: DBConnection.Poolboy

In https://github.com/ankhers/mongodb/blob/master/lib/mongo.ex

@pool Application.get_env(:mongodb, :pool, DBConnection.Connection)

& in https://github.com/ankhers/mongodb/blob/master/lib/mongo.ex#L887

Keyword.put_new(opts, :timeout, @timeout)
|> Keyword.put_new(opts, :pool, @pool)

[ankhers]

I do not think that would be the best option. A number of people I have spoken with use multiple mongo connections in their application(s) (think multi tenant). I am unsure if they are actually using the same pool type for every connection.

I will try to speak to the db_connection team about this.

[sauvainr]

I dont see a conflict unless I am missing something about db_connection. If different databases are used each of them needs a dedicated pool.

The pool: DBConnection.Poolboy specific the pool module, not the pool itself which is unique per conn.
So in a multi database case it would still be separated pools using the same pooling logic.

In my proposal, if the application (for any reason) wants different pulling options for different database, the application could still define the default pooling module in the configuration file and defines the specific pool module for the exception specific case.

And again if the application always defines the pool option as the case currently it would still work the same.

[theevangelista]

I also think that specifying a pool per connection is better, but in cases that are necessary could be an option on the query to execute it on another pool. For example if I start a mongo connection :foo with poolboy all mongo operations under the :foo connection would use the pool set at init. Otherwise we could maintain the pool option on the API for comparability and edge cases but not require.

I'll try to look into it this weekend

[theevangelista]

I looked at the codebase, here are my findings:

We need somehow get the :pool from the Mongo.start_link/2 function to be available as a default. I think it is stored inside the Mongo.Topology's GenServer. So we get that and merge with the options given to the query, if present on the query we accept the one from it otherwise we fetch from the Topology. I would implement this, but after some tries I think I lack the ability to do it :(

[CyrusNuevoDia]

Hey all, I'm not sure how useful this is, but I found a workaround for this.

Check out this Gist.

It's not self-sufficient to copy/paste into your project, but it should give you an idea of how to go about doing it.