MinimongoError: Invalid modifier specified $min
at MinimongoError (packages/minimongo/minimongo.js:44:1)
at Function._.each._.forEach (packages/underscore/underscore.js:113:1)
at Function.LocalCollection._modify (packages/minimongo/modify.js:40:1)
at simulateUpsertWithInsertedId (packages/mongo/mongo_driver.js:704:21)
at MongoConnection._update (packages/mongo/mongo_driver.js:543:7)
at MongoConnection.<anonymous> (packages/meteor/helpers.js:118:1)
at MongoConnection.(anonymous function) [as update] (packages/mongo/mongo_driver.js:771:49)
at [object Object].update (packages/mongo/collection.js:589:29)
On the server. I’m trying to use some operators like $min and $max update operators, but apparently Meteor’s mongo implementation is incomplete? Using rawCollection() solves this, but I would rather use Meteor exposed methods.
This is an error from MiniMongo (Meteor’s MongoDB implementation for the browser) - are you sure you’re executing this on the server? Maybe it’s in a method with code shared between client and server and it gets executed due to client simulating this method?
The solution to this is that Minimongo is a second order wrapper on the node mongo driver. The node mongo driver is up-to-date with MongoDB 3.2.6, but that doesn’t imply that the Minimongo wrapper on top of it is up-to-date. The fix is to use myCollection.rawCollection(), which exposes the underlying node-mongo implementation. Then things like $max, $min, findAndModify can be used.
I’m pretty sure that in normal operation MiniMongo doesn’t get called, because I did use some Mongo 3.2 features on the server before without problems.
I was following the source code and it seems that MiniMongo gets called by simulateUpsertWithInsertedId() method only if you’re doing an upsert() with insertedId parameter, and it seems like a bug, because that code shouldn’t be called when using Mongo 2.6 or later:
The point is that this method has to be compatible with Mongo 2.4, so in my opinion there should be a check there whether the Mongo version >= 2.6 and if so, use the proper MongoDB collection call instead of the MiniMongo-backed LocalCollection.
I like this. Now I’m questioning why the minimongo code needs to accessed
in the first place. I’m thinking it’s for server-to-server connections,
whereby one server plays the role of the client with respect to the other
server. I’m curious why it’s called for a collection which is owned by the
server, though. Even for other versions of mongo, wouldn’t it make more
sense to interact with node-mongo directly?
We should probably detect when it’s a sufficiently new version, and not use it! I think this would be a great PR to open for someone interested, especially since the implementation might not be too complicated.
I assume this is to avoid surprises where the server behaves differently for the client.
Also, it would be great to add min and max, could be a great PR as well, shouldn’t be too difficult.