Anyone knows how to upgrade a Meteor project’s built-in mongodb (shell and server)?
I don’t think it could be very easy, if at all possible with reasonable effort. Why would you want to do that anyway? Just set up a testing environment that has 3.0.x MongoDB and keep developing on 2.6.x. Or do you need specific features of 3.0.x even during development?
I’d be interested to hear about your motivation, even if I can’t provide much of assistance about the actual question, except to say that I can confirm that Meteor generally works on MongoDB 3.0.x (for my projects, anyway)!
so i’ll start off by saying upgrading in general works so far (I’ve linked my project to a 3.0.3 WiredTiger deployment on AWS)
I’ve read through the Meteor repo to realize that when you install Meteor, it actually pulls an MDG forked version of MongoDB (they have a bunch of modifications related to SSL, afaik)
That means it’s indeed hard or practically impossible to upgrade the dev bundle
Anyway, my motivation is to keep the dev environment as “intact” as possible, that is:
- minimze differences between dev and production
- utilize the natural work process (i.e. auto installing the dev db along with Meteor) and running the right shell version when using “meteor mongo”. why? cause I got more developers coming and I’d like onboarding to be simple, avoiding extra devops. Also, a small divergence sometimes evolves to trouble
Yeah, I agree and I like your thinking! If that’s hugely important then I think for now it might be better to stick with MongoDB 2.6.x.
But wait – why don’t you just use something like
MONGO_URL=mongodb://localhost:27017/my_app_on_3_0_x meteor
for running the local dev instance? That would actually give you the real thing, even without MDG’s changes in the forked version (not that that is likely at all to cause any issues).
I do that for some projects, e.g. when there’s pre-existing MongoDB data or if it’s important to have good performance (so choosing 3.0 makes sense) or it would be inconvenient to lose the DB and so a proper MongoDB instance feels a bit safer. Just create a simple script for all devs to use that’ll run meteor with that env param in front and you’re good, and it’s not harder to type (people just have to remember).
Also, think about using Docker, at least for the MongoDB instance, for use across dev/staging/prod environments if you think the “intactness” of DB environment and/or the automation benefits are worth it.
I’m also bringing lots of new Meteor devs on board, but for us so far it works well to just use default MongoDB on every project, and so it wasn’t worth introducing something like Docker yet, but I do use it on other projects and the benefits can be significant.
1 Like
the only disadvantage is you can’t use “meteor mongo” when you specify a MONGO_URL
other than that, I would have to compromise and use 2.6.x for the time being, as hacking the meteor dev bundling is too much a digression
Nevertheless, docking the mongoDB is a good suggestion that I should explore
1 Like
You forgot, I assume, that then you can simply leave out the “meteor” and just do mongo (with DB name appended, though, if you want the right DB to be preselected). The meteor mongo command just opens the standard mongo CLI tool, but absolves you of the hassle of figuring out which port Meteor’s built-in mongo instance is listening on!
1 Like
yeah, you’re right… it’s a very petty detail
alright, 2.6.x it is 