These are chat archives for Automattic/mongoose

31st
Mar 2015
Hengki Sihombing
@hengkiardo
Mar 31 2015 05:07
@vkarpov15 mongoose v4 is ready using for production?
because i still getting warning message like this https://cldup.com/f_FH6PSEYC.png
Liam Mitchell
@LiamKarlMitchell
Mar 31 2015 05:45
What is the stable version anyway, http://mongoosejs.com/ does not appear to say?
Maksim
@chetverikov
Mar 31 2015 06:25
@aredo Hi, yes, ready. This bug fixed in 4.0.1 —> #2794
Liam Mitchell
@LiamKarlMitchell
Mar 31 2015 06:27
Ah thanks
Valeri Karpov
@vkarpov15
Mar 31 2015 15:55
@LiamKarlMitchell 4.0.1 is the latest stable. mongoosejs.com no longer has that message because all releases >= 4.0.0 will be considered "stable"
Valeri Karpov
@vkarpov15
Mar 31 2015 16:03
So 4.1 will not be an unstable development release. Reason for this is so that releases are small, focused, and get fast feedback, rather than a monolithic all-at-once release. ATM, 3.8.x is exactly 666 commits behind master (https://github.com/Automattic/mongoose/tree/3.8.x), or 14% of the library's commit history. 3.8.x vs 3.6.x is even wider. This makes releases much scarier than they need to be - I'll sleep much better at night after pushing 4.1 if it's only maybe 20-50 commits ahead of 4.0
Tyler Mace
@tylerdmace
Mar 31 2015 20:55
I've got an app that needs to make a database connection upon login for each user (each user has a custom database that provides data necessary for our app). I wrote a crappy little connection manager to help facilitate this but I am undoubtedly creating/closing connections incorrectly. Does anyone have experience with this type of setup? Any best practices or suggestions on how to manage all the connections?
Liam Mitchell
@LiamKarlMitchell
Mar 31 2015 23:45
Yeah I agree minimal is better, thanks for the background on it :)

@tylerdmace To me it sounds like you may be better off firing up child processes to manage requests from each user depending on the db they need rather than managing a connection pool per db?

If you are writing software as a service then that could be way to go?
Although others may argue you should have a different server/virtual machine/deployment altogether.

Having child processes may separate your concerns of (What happens if program X crashes everyone else can't use it?, and could also mitigate worries about any sensitive information leaking out to another user)

But I digress