useDb and new connections

486 views
Skip to first unread message

Barry Kaplan

unread,
Feb 1, 2015, 5:16:07 AM2/1/15
to mongoo...@googlegroups.com
I am employing useDb() to support a multi-tenant app so I invoke useDb() for every request. After creating my first query that uses populate() I always got the error indicating the referenced model has not been loaded. Setting breakpoints and looking at the connection I saw that indeed only a single model was ever defined on the connection. 

Digging further, it looks like useDb() always creates a new connection on every invocation -- even if the connection to the same db has already previously been established. Am I reading this correctly? It is the applications job to cache the connection? (I'm not so clear yet, but I pretty sure this connection is the mongoose connection, not the pooled mongo-native connection.)

Valeri Karpov

unread,
Feb 2, 2015, 11:14:52 AM2/2/15
to mongoo...@googlegroups.com
Correct, useDb always creates a new connection. Under the hood, this connection uses the same underlying node driver connection pool though.

Whether it should cache is a kinda tricky question, but right now if you want caching of db connections you have to implement it yourself.

Pai-Hung Chen

unread,
Feb 2, 2015, 1:15:29 PM2/2/15
to mongoo...@googlegroups.com
Maybe useDb() can take an option for the caller to indicate whether caching is desired. This would be very handy if the caller wants to preserve the per-connection context such as all the models defined on the connection.

--
Documentation - http://mongoosejs.com/
Plugins - http://plugins.mongoosejs.com/
Bug Reports - http://github.com/learnboost/mongoose
Production Examples - http://mongoosejs.tumblr.com/
StackOverflow - http://stackoverflow.com/questions/tagged/mongoose
Google Groups - https://groups.google.com/forum/?fromgroups#!forum/mongoose-orm
Twitter - https://twitter.com/mongoosejs
IRC - #mongoosejs
---
You received this message because you are subscribed to the Google Groups "Mongoose Node.JS ODM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-orm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Valeri Karpov

unread,
Feb 2, 2015, 2:27:29 PM2/2/15
to mongoo...@googlegroups.com
I don't think that'll be a core mongoose feature. Swapping out the connection underlying a model sounds like it'll have some unpredictable behavior with things like populate().
To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-orm+unsubscribe@googlegroups.com.

Pai-Hung Chen

unread,
Feb 2, 2015, 2:32:56 PM2/2/15
to mongoo...@googlegroups.com
Yes, I agree this is better managed by the application itself.

From: Valeri Karpov
Sent: ‎2/‎2/‎2015 11:27 AM
To: mongoo...@googlegroups.com
Subject: Re: [mongoose] Re: useDb and new connections

To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-orm...@googlegroups.com.

Barry Kaplan

unread,
Feb 2, 2015, 8:29:20 PM2/2/15
to mongoo...@googlegroups.com

On Tuesday, February 3, 2015 at 12:57:29 AM UTC+5:30, Valeri Karpov wrote:
I don't think that'll be a core mongoose feature. Swapping out the connection underlying a model sounds like it'll have some unpredictable behavior with things like populate().3

By this do you mean swapping out the native connection under the mongoose connection that contains the models?

I agree this could be a problem, however in multi-tenant apps (well, ours at least) all the underlying "schemas" for each tenant are identical. Do you have any specifics in mind that might cause problems? 

Of course it is no great burden for the app to handle caching the results of useDb so long as the the actual underlying connection pool to the mongo servers is still being used.

Valeri Karpov

unread,
Feb 3, 2015, 10:28:51 AM2/3/15
to mongoo...@googlegroups.com
Population and versioning are the two issues I can think of off the top of my head. If the model's database changes, that means that document.populate() will always return empty results. Also, any outstanding document from before the database switch will fail to save if versioning is on (or save to the incorrect database if versioning is off). If the underlying schema is identical then you can just reuse the schema to create multiple models, no?
Reply all
Reply to author
Forward
0 new messages