Skipping connection pools or sharing them between multiple Knex instances

[moll]

Hey,

I'm writing a library that would like to use Knex for its query building, but don't want to advertise that fact outside the library. I also don't want to everyone to run more than one connection pool.

How would you envision sharing connection pools between Knex and the outside world? Perhaps settle on some standard type of a pool or just a couple of functions with an agreed upon signature for getting a connection and releasing it?

Or perhaps ignore Knex's pooling at all and try to have it run the query directly on a Pg.Client instance given to it? Currently unfortunately they seem so coupled... Knex passing SQL arrays to multi query functions passing builders with SQL to client wrappers to... somethings.

Could you perhaps give an answer off the top of your head for now how to take a Knex built query and run it on the Pg.Client instance given to it, skipping all of the pooling and mooling? Thanks!

[tgriesser]

Everything will be very decoupled in the next release - take a look here for what I'm thinking for the pool facade... If you can wait a few days till I wrap that up, that would probably be your best bet...

[moll]

That's good! I can wait. Thanks.
Will it be possible to use any object that has acquire and release in place of your own pool module?

[tgriesser]

Yes, it'll be possible to do that.

[moll]

Superb. Thanks!

[tgriesser]

@moll - so 0.4.0 is out... the client and pool both have an extend method similar to Backbone's extend, and you should be able to sub-class the client to create a custom one, swapping in methods and whatnot wherever you want. I could go into more detail, but I'm guessing you can figure it out... http://knexjs.org/docs/clients/pool.html - feel free to ping me with additional questions though.

[moll]

Hey,

Thanks though I still don't see a way to do what I was thinking before, so maybe you can shine some light:

First, didn't really want to subclass pool, more like wanted to pass an outside pool instance into Knex as a way to share connections between the parent app and any library. This way a library wanting to making queries on behalf of the parent app need not concern the parent with Knex. Knex is a query builder, after all.

From what I'm seeing, 0.4.0 has Knex as a constructor which takes config. This config, without the client property, is passed to ServerBase. ServerBase however takes only configuration hashes and initializes its own pool and expects to have access to the configuration parameters of a database.

What I was more after is having Knex use an existing pool that has no knowledge of Knex, merely that it has two methods acquire and release as its public interface. And perhaps the type of the database so Knex would know which adapter to use for building queries.

On that topic — is there a pool library that would actually take care of connecting, too? I see you're implementing getRawConnection in Knex, whereas I'd imagine it should be in a "pg-pool" type object. Currently querying and connection initialization are in the same class.

[tgriesser]

You can now use the .connection method in 0.6 to explicitly specify a connection.

[moll]

👍