Ако приемем елементите във вашите products масив са уникални, няма лесна поддръжка от страна на сървъра за поддържане на този масив в сортиран ред, както при MongoDB 2.4. Най-добрата ви опция, предвид вложените масиви, ще бъде да сортирате масивите в логиката на вашето приложение, както е подходящо (т.е. при вмъкване/актуализиране или при извличане/показване).
Съображения за моделиране на данни
Ако трябва да извършите много манипулации на вложени записи в масив, трябва да помислите за изравняване на вашия модел на данни, за да улесните работата с него. Вашата цел при проектиране с MongoDB трябва да бъде да имате модел на данни, който е подходящ за вашите случаи на използване на приложението с приемлив баланс на производителност между лекота на вмъкване/актуализиране/запитване. Определено не е нужно да моделирате всичко в една колекция/заявка, ако няма смисъл да го правите, и трябва да сте готови да денормализирате (дублирате) данни. За връзката много към много, като продукти <=> категории, е типично да се вгради и денормализира всеки обект, който се актуализира по-рядко (например вграждане на категории в продукти).
Постоянни сортирани, ограничени масиви (неуникални елементи)
Ако искате да запазите масивите в сортиран ред и елементите не са уникални, MongoDB 2.4 има опция за $push
към сортиран масив, но това трябва да се използва заедно със срез (ограничение на масива). Ако $push идентични записи в сортиран масив ще се окажете с дубликати (така че това вероятно не е това, което търсите).
Примерна актуализация, като се приема page във вашия пример беше името на колекцията:
db.page.update(
// Query
{ "_id": "56rgt46rt54h68rt4h6" },
// Update sorted array
// NB: referring by array index position 0, as there isn't a named reference
{ $push : {
"categories.0.products" : {
// List of new elements to push
$each : [
{ "name" : "E", "pos": 3 }
],
// Sort by pos (ascending)
$sort : { "pos" : 1 },
// Maximum number of array elements (required for $sort)
$slice : -100
}
}}
)
