compound indexes

[selaias]

great idea in including indexing options at field level. Although it will serve every day needs, I wonder how this could be extended to manage compound indexes and Index intersection for more advanced apps that aim to use covered queries for better performance. I guess it should be at collection level?

[Ragsboss]

+1, we also have a need to define compound unique key. For example, fields 'foo' and 'bar' are both non-optional and we want the combination to be unique.

[dpankros]

or perhaps specify the name of the index on each field and then define the index at the collection level, including the same name. E.g.

Schema = new SimpleSchema {
 compoundField1: {
  type: Number,
  name: 'Compound Field 1',
  index: 'compound_index_1'
},
compoundField2: {
  type: Number,
  name: 'Compound Field 2',
  index: ['compound_index_1', 'index2'] //<-- note MULTIPLE indexes on the same field
}
...
}
Collection = new Mongo.Collection('collection');
Collection.attachSchema(Schema);
Collection.attachIndex('compound_index_1', {
  unique: true,
  background: false,
  //sparse: false,
  //partialFilterExpression: xxx
  //expireAfterSeconds: xxx
  //storageEngine: xxx
  //and so on
  //basically all the mongo properties could be passed through to createIndex
});
Collection.attachIndex('index2'); //just use the deafults.  e.g. simple, ascending index

Thoughts?

[derwaldgeist]

That's the very first issue, but it hasn't been resolved yet. Did anyone try to implement this yet? We have a use-case where compound indexes are important.

[dpankros]

If I recall, I did add it @derwaldgeist but in my own fork. I don't know that it was ever merged. It's hard for me to remember as it was 9 years ago and I've been out of the meteor community for a while.

It might be worthwhile to diff my branch against its base and see what was changed. I wish I could be more helpful. Sorry.

[derwaldgeist]

I wish I could be more helpful. Sorry.

No prob. I solved this by setting the index using collection._ensureIndex() now, and it worked fine, both locally and on MongoDB ATLAS. I just hope this undocumented function will be upwards compatible, especially when upgrading to Meteor 3.0.