Inserting a composite key gives: "Meteor does not currently support objects other than objectid as ids"


Read from here that the best way to do composite keys is by:

var key = {_id:{a:1, b:1}};

However, this throws the following error:
Error: Meteor requires document _id fields to be non-empty strings or ObjectIDs

Is this unsupported in meteor? I don’t understand why it would require support? Isn’t this just a mongo feature that you can use json objects as ObjectIds?

Should I just be letting mongo create a _id and I just index my a and b fields as a compound index instead?

Ground:DB trouble grounding exisiting collection w/ ReactJS

It might have to do with limitations of minimongo. Minimongo only supports an index on the _id field and it is possible that they don’t support anything other than simple ObjectIds.

The easy solution, as you mentioned is to simply create a new index. You can make it unique, so it is basically the same thing as _id.


I read about minimongo limitations but it shouldn’t apply as I’m doing a 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.

    uid: {
        type: String,
        index: 1,
        autoform: {
    oid: {
        type: String,
        index: 1,
        autoform: {


From a recent blog post:

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

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.


Agreed. Even on the server, Meteor uses minimongo for collection methods. As @babrahams says, if you need vanilla MongoDB methods, you will need to use rawCollection() and risk losing Meteor magic.


Oh noes! I want the magic! Composite keys are not worth losing the magic over, but it’s good to know there is that option in the future. It’s worked well enough with just composite indexes atm.