Assumindo os itens em seus
products array são únicos, não há nenhum suporte fácil do lado do servidor para manter esse array em ordem de classificação como no MongoDB 2.4. Sua melhor opção, considerando as matrizes aninhadas, será classificar as matrizes na lógica do aplicativo conforme apropriado (ou seja, na inserção/atualização ou na recuperação/exibição). Considerações de modelagem de dados
Se você precisar fazer muita manipulação de entradas de matriz aninhadas, considere nivelar seu modelo de dados para facilitar o trabalho. Seu objetivo de design com o MongoDB deve ser ter um modelo de dados apropriado para seus casos de uso de aplicativos com equilíbrio de desempenho aceitável entre facilidade de inserção/atualização/consulta. Você definitivamente não precisa modelar tudo em uma única coleção/consulta se isso não fizer sentido, e você deve estar preparado para desnormalizar (duplicar) dados. Para relacionamentos muitos para muitos, como categorias <=> de produtos, é comum incorporar e desnormalizar qualquer entidade que seja atualizada com menos frequência (por exemplo, incorporar categorias em produtos).
Matrizes classificadas e limitadas persistentes (itens não exclusivos)
Se você deseja persistir arrays em ordem classificada e os itens não são exclusivos, o MongoDB 2.4 tem a opção de
$push
para uma matriz ordenada, mas isso deve ser usado em conjunto com uma fatia (limite de matriz). Se você $push entradas idênticas a uma matriz classificada, você terminará com duplicatas (portanto, isso provavelmente não é o que você está procurando). Atualização de exemplo, assumindo
page no seu exemplo era o nome da coleção: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
}
}}
)
