2011-10-26 4 views
2

Lorsque j'appelle ensureIndex du shell mongo sur une collection pour un index composé, un champ _id de type ObjectId est généré automatiquement dans l'objet index.Appel de ensureIndex avec les résultats de clé composés dans le champ _id dans l'objet index

> db.system.indexes.find(); 
{ "name" : "_id_", "ns" : "database.coll", "key" : { "_id" : 1 } } 
{ "_id" : ObjectId("4ea78d66413e9b6a64c3e941"), "ns" : "database.coll", "key" : { "a.b" : 1, "a.c" : 1 }, "name" : "a.b_1_a.c_1" } 

Cela est logique intuitive que tous les documents dans une collection besoin d'un champ _id (même les system.indexes, non?), Mais quand je vérifie les index générés par l'appel de ensureIndex de morphia pour la même collection * il n'y a _id propriété *. En regardant le code source de morphia, il est clair qu'il appelle le même code que le shell, mais pour une raison quelconque (que ce soit en créant un index composé ou en indexant un document Embedded ou les deux), ils produisent résultats différents. Quelqu'un peut-il m'expliquer ce comportement?

Répondre

1

pas exactement comment vous avez réussi à obtenir un champ _id dans la collection d'index, mais les deux shell et Morphia son origine ensureIndex appelle des index composés ne mettent pas un champ _id dans l'objet index:

> db.test.ensureIndex({'a.b':1, 'a.c':1}) 
> db.system.indexes.find({}) 
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "test.test", "name" : "_id_" } 
{ "v" : 1, "key" : { "a.b" : 1, "a.c" : 1 }, "ns" : "test.test", "name" : "a.b_1_a.c_1" } 
> 

Mise à jour vers 2.x si vous utilisez une ancienne version pour éviter de rencontrer des problèmes résolus. Et à en juger par votre sortie, vous exécutez 1.8 ou plus tôt.

+0

Merci, c'est exactement vrai - la version de mongod sur laquelle morphia créait index était une version plus récente que la version à laquelle le shell se connectait. brasser installé l'ancien 1.6.3, et la commande mongo frappait cette version plus tôt dans mon $ PATH. – jpredham

+0

Voilà! –

Questions connexes