Restrições de índice curinga

Regras de validação do wildcardProjection

Começando no MongoDB 8.2.4 (e 8.0.18, 7.0.29), regras de validação mais rigorosas se aplicam a wildcardProjection em índices curinga compostos para evitar configurações inválidas.

Os índices existentes que não atendem aos novos requisitos de validação continuam a funcionar, mas você não pode criar novos índices que não atendam a esses requisitos.

Ao utilizar wildcardProjection com índices curinga compostos, as seguintes regras se aplicam:

{ productId: 1, "$**": 1 },
{
  wildcardProjection: {
    attributes: 1
  }
}

{ productId: 1, "$**": 1 },
{
  wildcardProjection: { }
}

{ "$**": 1, category: 1 },
{
  wildcardProjection: {
    _id: 0,
    attributes: 1
  }
}

{ "$**": 1, category: 1 },
{
  wildcardProjection: {
    _id: 1,
    metadata: 0
  }
}

{ "$**": 1, category: 1 },
{
  wildcardProjection: {
    _id: 0,
    price: 0,
    stock: 1
  }
}

{ userId: 1, "$**": 1 },
{
  wildcardProjection: {
    preferences: 1
  }
}

{ userId: 1, "$**": 1 },
{
  wildcardProjection: {
    userId: 1
  }
}

{ _id: 1, "$**": 1 },
{
  wildcardProjection: {
    _id: 0
  }
}

{ productId: 1, "$**": 1 },
{
  wildcardProjection: {
    _id: 0
  }
}

{
  userId: 1,
  category: 1,
  "$**": 1
},
{
  wildcardProjection: {
    userId: 0,
    category: 0
  }
}

{
  userId: 1,
  category: 1,
  "$**": 1
},
{
  wildcardProjection: {
    userId: 0
  }
}

O campo de array não é igual a null

Se um determinado campo for uma array em qualquer documento da coleção, os índices curinga não poderão suportar queries para documentos em que esse campo não seja igual a null.

Por exemplo, considere uma coleção inventory com um índice curinga em product_attributes. O índice curinga não pode suportar as seguintes queries se product_attributes.tags for uma array em qualquer documento da coleção:

db.inventory.find( { $ne : [ "product_attributes.tags", null ] } )
db.inventory.aggregate( [
   {
      $match : { $ne : [ "product_attributes.tags", null ] }
   }
] )

Correspondências de igualdade em documentos e arrays

Os índices curinga armazenam entradas para o conteúdo de um documento ou array, não o documento ou array em si. Portanto, os índices curinga não podem suportar correspondências exatas de igualdade em documentos ou arrays.

Por exemplo, considere uma collection inventory com um índice curinga em product_attributes. O índice curinga não pode suportar as seguintes queries:

db.inventory.find(
   {
      "product_attributes" : { "price" : 29.99 }
   }
)
db.inventory.find(
   {
      "product_attributes.tags" : [ "waterproof", "fireproof" ]
   }
)

Da mesma forma, os índices curinga não suportam correspondências exatas de desigualdade em documentos e arrays. Por exemplo, um índice curinga em product_attributes não pode suportar as seguintes queries:

db.inventory.aggregate( [
   {
      $match : {
         $ne : [ "product_attributes", { "price" : 29.99 } ]
      }
   }
] )
db.inventory.aggregate( [
   {
      $match : {
         $ne : [ "product_attributes.tags", [ "waterproof", "fireproof" ] ]
      }
   }
] )

O campo não existe

Os índices curinga são esparsos e não indexam campos vazios. Portanto, os índices curinga não podem suportar queries para documentos onde um campo não existe.

Por exemplo, considere uma collection inventory com um índice curinga em product_attributes. O índice curinga não pode suportar as seguintes queries:

db.inventory.find(
   {
      "product_attributes" : { $exists : false }
   }
)
db.inventory.aggregate( [
  {
     $match : {
        "product_attributes" : { $exists : false }
     }
  }
] )

Predicados de query de vários campos

Caso um único índice curinga possa suportar vários campos de query, o MongoDB só pode usar o índice curinga para suportar um dos campos de query.

Por exemplo, considere uma collection inventory com um índice curinga em product_attributes. O índice curinga não pode suportar todos os predicados na seguinte query:

db.inventory.find(
   {
      "product_attributes.price": { $gt: 20 },
      "product_attributes.material": "silk",
      "product_attributes.size": "large"
   }
)

Em vez disso, o MongoDB utiliza o índice curinga para suportar apenas um dos predicados da query. O MongoDB escolhe automaticamente qual predicado suportar com base em caminhos de índice curinga relevantes. Os predicados de query não suportados são mostrados no rejectedPlans dos resultados da explicação.

Isso também se aplica a índices curinga. O termo curinga de um índice composto só pode oferecer suporte a um predicado de query, embora os termos não curinga possam oferecer suporte aos predicados restantes.

Consultas com Classificação

O MongoDB pode usar um índice curinga para satisfazer sort() somente se todas as condições a seguir forem verdadeiras:

• O planejador de query seleciona o índice curinga para satisfazer o predicado da query.

• O sort() especifica somente o campo de predicado da query.

• O campo especificado nunca é uma matriz.

Se as condições acima não forem atendidas, o MongoDB não poderá usar o índice curinga para a classificação. O MongoDB não suporta operações do sort() que exigem um índice diferente do predicado da query.

Considere o seguinte índice curinga na collection products:

db.products.createIndex( { "product_attributes.$**" : 1 } )

A seguinte operação faz queries para um campo único product_attributes.price e classifica neste mesmo campo:

db.products.find(
  { "product_attributes.price" : { $gt : 10.00 } },
).sort(
  { "product_attributes.price" : 1 }
)

Supondo que o price especificado nunca seja uma array, o MongoDB pode usar o índice curinga product_attributes.$** para satisfazer tanto find() quanto sort().