I read about minimongo limitations but it shouldn’t apply as I’m doing a Meteor.call and playing around with it on the serverside (forgot to mention this was a server call).
It worked from the mongo shell, but couldn’t find any info that specifically said you can’t have objects as objectids in meteor serverside.
The stackoverflow question hinted that composite keys was the better way to go which is why I asked but I’ve just done it with two composite indexes using collections2 by aldeed. I’m maintaining the uniqueness of the combination in server logic. Not sure if the unique field does it across all fields or just for each field.
The Meteor server now provides raw access to the collection and database objects in the npm MongoDB driver (through rawCollection and rawDatabase methods on Mongo.Collection) and to all the options supported by npm request module (through HTTP.call).
Using Meteor collections to make db updates on the server isn’t the same as using the the mongo shell, even though it feels a lot like it syntactically.
If you make a collection of objects with composite keys, you probably won’t be able to use any of the goodness and light that Meteor provides to interact with that collection, except by calling methods and using YourCollection.rawCollection to interact with the db. That’s my guess, anyway.