-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compound indexes #1
Comments
+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. |
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? |
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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: