Znajdź rekordy MongoDB, w których pole tablicy nie jest puste

502

Wszystkie moje rekordy mają pole o nazwie „zdjęcia”. To pole jest tablicą ciągów.

Chcę teraz 10 najnowszych rekordów, w których ta tablica NIE JEST pusta.

Grzebałem w Internecie, ale o dziwo nie znalazłem wiele na ten temat. Przeczytałem opcję $ where, ale zastanawiałem się, jak powolne jest to dla funkcji natywnych i czy istnieje lepsze rozwiązanie.

I nawet wtedy to nie działa:

ME.find({$where: 'this.pictures.length > 0'}).sort('-created').limit(10).execFind()

Nic nie zwraca. Pozostawienie this.picturesbez bitu długości działa, ale potem zwraca również puste rekordy.

mongodb  mongoose 
— skerit
źródło

Odpowiedzi:

827

Jeśli masz także dokumenty, które nie mają klucza, możesz użyć:

ME.find({ pictures: { $exists: true, $not: {$size: 0} } })

MongoDB nie używa indeksów, jeśli zaangażowany jest rozmiar $, więc oto lepsze rozwiązanie:

ME.find({ pictures: { $exists: true, $ne: [] } })

Od wydania MongoDB 2.6 można porównać z operatorem, $gtale może to prowadzić do nieoczekiwanych rezultatów (szczegółowe wyjaśnienie można znaleźć w tej odpowiedzi ):

ME.find({ pictures: { $gt: [] } })
— Chris
źródło
6
Dla mnie jest to prawidłowe podejście, ponieważ zapewnia, że ​​tablica istnieje i nie jest pusta.
— LeandroCR,
Jak mogę osiągnąć tę samą funkcjonalność za pomocąmongoengine
— Rohit Khatri
54
UWAŻNY, ME.find({ pictures: { $gt: [] } })JEST NIEBEZPIECZNY, nawet w nowszych wersjach MongoDB. Jeśli masz indeks na polu listy i ten indeks jest wykorzystywany podczas zapytania, otrzymasz nieoczekiwane wyniki. Na przykład: db.doc.find({'nums': { $gt: [] }}).hint({ _id: 1 }).count()zwraca właściwą liczbę, podczas gdy db.doc.find({'nums': { $gt: [] }}).hint({ nums: 1 }).count()zwraca 0.
— wojcikstefan
1
Zobacz moją szczegółową odpowiedź poniżej, aby dowiedzieć się, dlaczego to może nie działać dla ciebie: stackoverflow.com/a/42601244/1579058
— wojcikstefan
6
Komentarz @ wojcikstefan musi zostać poddany głosowaniu, aby uniemożliwić ludziom skorzystanie z ostatniej sugestii, która w pewnych okolicznościach nie zwraca pasujących dokumentów.
— Thomas Jung
181

Po kilku bardziej zaglądających, szczególnie w dokumentach mongodb i zagadkach razem, oto odpowiedź:

ME.find({pictures: {$exists: true, $not: {$size: 0}}})
— skerit
źródło
27
To nie działa Nie wiem, czy to wcześniej działało, ale zwróci również obiekty, które nie mają klawisza „obrazki”.
— rdsoze
17
Niewiarygodne, jak ta odpowiedź ma 63 pozytywne głosy, gdy w rzeczywistości to, co powiedział @rdsoze, jest prawdą - zapytanie zwróci również rekordy, które nie mają picturespola.
— Dan Dascalescu
5
Uważaj, mongoDB nie będzie używać indeksów, jeśli zaangażowany jest rozmiar $ link . Lepiej byłoby dołączyć {$ ne: []} i ewentualnie {$ ne: null}.
— Levente Dobson,
17
@rdsoze pierwszy wiersz pytania brzmi: „Wszystkie moje rekordy mają pole o nazwie„ zdjęcia ”. To pole jest tablicą” . Co więcej, jest to całkowicie realistyczny i powszechny scenariusz. Ta odpowiedź nie jest zła, działa na pytanie dokładnie tak, jak zostało napisane, a krytykowanie lub odrzucanie go za to, że nie rozwiązuje innego problemu, jest głupie.
— Mark Amery
1
@Cec Cała dokumentacja mówi, że jeśli użyjesz $ size w zapytaniu, nie użyje żadnego indeksu, aby dać ci szybsze wyniki. Więc jeśli masz indeks w tym polu i chcesz go użyć, trzymaj się innych podejść, takich jak {$ ne: []}, jeśli to działa dla Ciebie, to użyje twojego indeksu.
— Levente Dobson
108

Może to również działać dla Ciebie:

ME.find({'pictures.0': {$exists: true}});
— tenbatsu
źródło
2
Miły! Pozwala to również sprawdzić minimalny rozmiar. Czy wiesz, czy tablice są zawsze indeksowane sekwencyjnie? Czy kiedykolwiek byłby przypadek, w którym pictures.2istnieje, ale pictures.1nie istnieje ?
— anushr
2
$existsOperator jest wartością logiczną, a nie offset. @tenbatsu powinien używać truezamiast 1.
— ekillaby
2
@anushr Would there ever be a case where pictures.2 exists but pictures.1 does not? Tak, taka sprawa może się zdarzyć.
— The Bndr
@TheBndr To może się zdarzyć tylko wtedy, gdy picturesjest to dokument podrzędny, a nie tablica. np.pictures: {'2': 123}
— JohnnyHK
4
Jest to miłe i intuicyjne, ale uważaj, jeśli wydajność jest ważna - wykona pełny skan kolekcji, nawet jeśli masz indeks pictures.
— wojcikstefan
35

Podczas zapytań zależy Ci na dwóch rzeczach - dokładności i wydajności. Mając to na uwadze, przetestowałem kilka różnych podejść w MongoDB v3.0.14.

TL; DR db.doc.find({ nums: { $gt: -Infinity }})jest najszybszy i najbardziej niezawodny (przynajmniej w testowanej wersji MongoDB).

EDYCJA: To już nie działa w MongoDB v3.6! Zobacz komentarze pod tym postem, aby znaleźć potencjalne rozwiązanie.

Ustawiać

Wstawiłem 1k dokumentów bez listy, 1k dokumentów z pustą listą i 5 dokumentów z niepustą listą.

for (var i = 0; i < 1000; i++) { db.doc.insert({}); }
for (var i = 0; i < 1000; i++) { db.doc.insert({ nums: [] }); }
for (var i = 0; i < 5; i++) { db.doc.insert({ nums: [1, 2, 3] }); }
db.doc.createIndex({ nums: 1 });

Zdaję sobie sprawę, że nie jest to wystarczająca skala, aby traktować wydajność tak samo poważnie, jak w poniższych testach, ale wystarczy przedstawić poprawność różnych zapytań i zachowanie wybranych planów zapytań.

Testy

db.doc.find({'nums': {'$exists': true}}) zwraca złe wyniki (za to, co próbujemy osiągnąć).

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': {'$exists': true}}).count()
1005

-

db.doc.find({'nums.0': {'$exists': true}})zwraca poprawne wyniki, ale jest również powolne przy użyciu pełnego skanowania kolekcji (uwaga COLLSCANna wyjaśnienie).

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums.0': {'$exists': true}}).count()
5
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums.0': {'$exists': true}}).explain()
{
  "queryPlanner": {
    "plannerVersion": 1,
    "namespace": "test.doc",
    "indexFilterSet": false,
    "parsedQuery": {
      "nums.0": {
        "$exists": true
      }
    },
    "winningPlan": {
      "stage": "COLLSCAN",
      "filter": {
        "nums.0": {
          "$exists": true
        }
      },
      "direction": "forward"
    },
    "rejectedPlans": [ ]
  },
  "serverInfo": {
    "host": "MacBook-Pro",
    "port": 27017,
    "version": "3.0.14",
    "gitVersion": "08352afcca24bfc145240a0fac9d28b978ab77f3"
  },
  "ok": 1
}

-

db.doc.find({'nums': { $exists: true, $gt: { '$size': 0 }}})zwraca złe wyniki. Wynika to z nieprawidłowego skanowania indeksu, który nie przesyła żadnych dokumentów. Prawdopodobnie będzie dokładny, ale powolny bez indeksu.

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $gt: { '$size': 0 }}}).count()
0
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $gt: { '$size': 0 }}}).explain('executionStats').executionStats.executionStages
{
  "stage": "KEEP_MUTATIONS",
  "nReturned": 0,
  "executionTimeMillisEstimate": 0,
  "works": 2,
  "advanced": 0,
  "needTime": 0,
  "needFetch": 0,
  "saveState": 0,
  "restoreState": 0,
  "isEOF": 1,
  "invalidates": 0,
  "inputStage": {
    "stage": "FETCH",
    "filter": {
      "$and": [
        {
          "nums": {
            "$gt": {
              "$size": 0
            }
          }
        },
        {
          "nums": {
            "$exists": true
          }
        }
      ]
    },
    "nReturned": 0,
    "executionTimeMillisEstimate": 0,
    "works": 1,
    "advanced": 0,
    "needTime": 0,
    "needFetch": 0,
    "saveState": 0,
    "restoreState": 0,
    "isEOF": 1,
    "invalidates": 0,
    "docsExamined": 0,
    "alreadyHasObj": 0,
    "inputStage": {
      "stage": "IXSCAN",
      "nReturned": 0,
      "executionTimeMillisEstimate": 0,
      "works": 1,
      "advanced": 0,
      "needTime": 0,
      "needFetch": 0,
      "saveState": 0,
      "restoreState": 0,
      "isEOF": 1,
      "invalidates": 0,
      "keyPattern": {
        "nums": 1
      },
      "indexName": "nums_1",
      "isMultiKey": true,
      "direction": "forward",
      "indexBounds": {
        "nums": [
          "({ $size: 0.0 }, [])"
        ]
      },
      "keysExamined": 0,
      "dupsTested": 0,
      "dupsDropped": 0,
      "seenInvalidated": 0,
      "matchTested": 0
    }
  }
}

-

db.doc.find({'nums': { $exists: true, $not: { '$size': 0 }}})zwraca poprawne wyniki, ale wydajność jest zła. Technicznie wykonuje skanowanie indeksu, ale następnie przesuwa wszystkie dokumenty, a następnie musi je przefiltrować).

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $not: { '$size': 0 }}}).count()
5
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $not: { '$size': 0 }}}).explain('executionStats').executionStats.executionStages
{
  "stage": "KEEP_MUTATIONS",
  "nReturned": 5,
  "executionTimeMillisEstimate": 0,
  "works": 2016,
  "advanced": 5,
  "needTime": 2010,
  "needFetch": 0,
  "saveState": 15,
  "restoreState": 15,
  "isEOF": 1,
  "invalidates": 0,
  "inputStage": {
    "stage": "FETCH",
    "filter": {
      "$and": [
        {
          "nums": {
            "$exists": true
          }
        },
        {
          "$not": {
            "nums": {
              "$size": 0
            }
          }
        }
      ]
    },
    "nReturned": 5,
    "executionTimeMillisEstimate": 0,
    "works": 2016,
    "advanced": 5,
    "needTime": 2010,
    "needFetch": 0,
    "saveState": 15,
    "restoreState": 15,
    "isEOF": 1,
    "invalidates": 0,
    "docsExamined": 2005,
    "alreadyHasObj": 0,
    "inputStage": {
      "stage": "IXSCAN",
      "nReturned": 2005,
      "executionTimeMillisEstimate": 0,
      "works": 2015,
      "advanced": 2005,
      "needTime": 10,
      "needFetch": 0,
      "saveState": 15,
      "restoreState": 15,
      "isEOF": 1,
      "invalidates": 0,
      "keyPattern": {
        "nums": 1
      },
      "indexName": "nums_1",
      "isMultiKey": true,
      "direction": "forward",
      "indexBounds": {
        "nums": [
          "[MinKey, MaxKey]"
        ]
      },
      "keysExamined": 2015,
      "dupsTested": 2015,
      "dupsDropped": 10,
      "seenInvalidated": 0,
      "matchTested": 0
    }
  }
}

-

db.doc.find({'nums': { $exists: true, $ne: [] }})zwraca prawidłowe wyniki i jest nieco szybszy, ale wydajność nadal nie jest idealna. Używa IXSCAN, który przesuwa dokumenty tylko z istniejącym polem listy, ale następnie musi odfiltrowywać puste listy jeden po drugim.

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $ne: [] }}).count()
5
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $exists: true, $ne: [] }}).explain('executionStats').executionStats.executionStages
{
  "stage": "KEEP_MUTATIONS",
  "nReturned": 5,
  "executionTimeMillisEstimate": 0,
  "works": 1018,
  "advanced": 5,
  "needTime": 1011,
  "needFetch": 0,
  "saveState": 15,
  "restoreState": 15,
  "isEOF": 1,
  "invalidates": 0,
  "inputStage": {
    "stage": "FETCH",
    "filter": {
      "$and": [
        {
          "$not": {
            "nums": {
              "$eq": [ ]
            }
          }
        },
        {
          "nums": {
            "$exists": true
          }
        }
      ]
    },
    "nReturned": 5,
    "executionTimeMillisEstimate": 0,
    "works": 1017,
    "advanced": 5,
    "needTime": 1011,
    "needFetch": 0,
    "saveState": 15,
    "restoreState": 15,
    "isEOF": 1,
    "invalidates": 0,
    "docsExamined": 1005,
    "alreadyHasObj": 0,
    "inputStage": {
      "stage": "IXSCAN",
      "nReturned": 1005,
      "executionTimeMillisEstimate": 0,
      "works": 1016,
      "advanced": 1005,
      "needTime": 11,
      "needFetch": 0,
      "saveState": 15,
      "restoreState": 15,
      "isEOF": 1,
      "invalidates": 0,
      "keyPattern": {
        "nums": 1
      },
      "indexName": "nums_1",
      "isMultiKey": true,
      "direction": "forward",
      "indexBounds": {
        "nums": [
          "[MinKey, undefined)",
          "(undefined, [])",
          "([], MaxKey]"
        ]
      },
      "keysExamined": 1016,
      "dupsTested": 1015,
      "dupsDropped": 10,
      "seenInvalidated": 0,
      "matchTested": 0
    }
  }
}

-

db.doc.find({'nums': { $gt: [] }})JEST NIEBEZPIECZNY, PONIEWAŻ W ZALEŻNOŚCI OD WYKORZYSTYWANEGO INDEKSU MOŻE Dawać NIEPODZIEWANE WYNIKI. Wynika to z nieprawidłowego skanowania indeksu, który nie przesyła żadnych dokumentów.

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $gt: [] }}).count()
0
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $gt: [] }}).hint({ nums: 1 }).count()
0
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $gt: [] }}).hint({ _id: 1 }).count()
5

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $gt: [] }}).explain('executionStats').executionStats.executionStages
{
  "stage": "KEEP_MUTATIONS",
  "nReturned": 0,
  "executionTimeMillisEstimate": 0,
  "works": 1,
  "advanced": 0,
  "needTime": 0,
  "needFetch": 0,
  "saveState": 0,
  "restoreState": 0,
  "isEOF": 1,
  "invalidates": 0,
  "inputStage": {
    "stage": "FETCH",
    "filter": {
      "nums": {
        "$gt": [ ]
      }
    },
    "nReturned": 0,
    "executionTimeMillisEstimate": 0,
    "works": 1,
    "advanced": 0,
    "needTime": 0,
    "needFetch": 0,
    "saveState": 0,
    "restoreState": 0,
    "isEOF": 1,
    "invalidates": 0,
    "docsExamined": 0,
    "alreadyHasObj": 0,
    "inputStage": {
      "stage": "IXSCAN",
      "nReturned": 0,
      "executionTimeMillisEstimate": 0,
      "works": 1,
      "advanced": 0,
      "needTime": 0,
      "needFetch": 0,
      "saveState": 0,
      "restoreState": 0,
      "isEOF": 1,
      "invalidates": 0,
      "keyPattern": {
        "nums": 1
      },
      "indexName": "nums_1",
      "isMultiKey": true,
      "direction": "forward",
      "indexBounds": {
        "nums": [
          "([], BinData(0, ))"
        ]
      },
      "keysExamined": 0,
      "dupsTested": 0,
      "dupsDropped": 0,
      "seenInvalidated": 0,
      "matchTested": 0
    }
  }
}

-

db.doc.find({'nums.0’: { $gt: -Infinity }}) zwraca prawidłowe wyniki, ale ma niską wydajność (używa pełnego skanowania kolekcji).

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums.0': { $gt: -Infinity }}).count()
5
MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums.0': { $gt: -Infinity }}).explain('executionStats').executionStats.executionStages
{
  "stage": "COLLSCAN",
  "filter": {
    "nums.0": {
      "$gt": -Infinity
    }
  },
  "nReturned": 5,
  "executionTimeMillisEstimate": 0,
  "works": 2007,
  "advanced": 5,
  "needTime": 2001,
  "needFetch": 0,
  "saveState": 15,
  "restoreState": 15,
  "isEOF": 1,
  "invalidates": 0,
  "direction": "forward",
  "docsExamined": 2005
}

-

db.doc.find({'nums': { $gt: -Infinity }})co zaskakujące, działa to bardzo dobrze! Daje właściwe wyniki i jest szybki, przesuwając 5 dokumentów z fazy skanowania indeksu.

MacBook-Pro(mongod-3.0.14) test> db.doc.find({'nums': { $gt: -Infinity }}).explain('executionStats').executionStats.executionStages
{
  "stage": "FETCH",
  "nReturned": 5,
  "executionTimeMillisEstimate": 0,
  "works": 16,
  "advanced": 5,
  "needTime": 10,
  "needFetch": 0,
  "saveState": 0,
  "restoreState": 0,
  "isEOF": 1,
  "invalidates": 0,
  "docsExamined": 5,
  "alreadyHasObj": 0,
  "inputStage": {
    "stage": "IXSCAN",
    "nReturned": 5,
    "executionTimeMillisEstimate": 0,
    "works": 15,
    "advanced": 5,
    "needTime": 10,
    "needFetch": 0,
    "saveState": 0,
    "restoreState": 0,
    "isEOF": 1,
    "invalidates": 0,
    "keyPattern": {
      "nums": 1
    },
    "indexName": "nums_1",
    "isMultiKey": true,
    "direction": "forward",
    "indexBounds": {
      "nums": [
        "(-inf.0, inf.0]"
      ]
    },
    "keysExamined": 15,
    "dupsTested": 15,
    "dupsDropped": 10,
    "seenInvalidated": 0,
    "matchTested": 0
  }
}
— wojcikstefan
źródło
Dziękujemy za bardzo szczegółową odpowiedź @wojcikstefan. Niestety sugerowane przez Ciebie rozwiązanie nie działa w moim przypadku. Mam kolekcję MongoDB 3.6.4 z 2-metrowymi dokumentami, z których większość ma seen_eventstablicę String, która również jest indeksowana. Wyszukiwanie za pomocą { $gt: -Infinity }, natychmiast otrzymuję 0 dokumentów. Używając { $exists: true, $ne: [] }, otrzymuję bardziej prawdopodobne dokumenty o wartości 1,2
— mln
Wygląda na to, że masz rację @Ncode - to już nie działa w MongoDB v3.6 :( Grałem z nim przez kilka minut i oto co znalazłem: 1. db.test_collection.find({"seen_events.0": {$exists: true}})jest zły, ponieważ używa skanowania kolekcji. 2. db.test_collection.find({seen_events: {$exists: true, $ne: []}})jest źle, ponieważ jego IXSCAN pasuje do wszystkich dokumentów, a następnie filtrowanie odbywa się w wolnej fazie pobierania. 3. To samo dotyczy db.test_collection.find({seen_events: {$exists: true, $not: {$size: 0}}}). 4. Wszystkie pozostałe zapytania zwracają nieprawidłowe wyniki.
— wojcikstefan
1
@NCode znalazł rozwiązanie! Jeżeli jesteś pewien, że wszystko niepusty seen_eventszawierają ciągi, można użyć tego: db.test_collection.find({seen_events: {$gt: ''}}).count(). Aby potwierdzić, że działa dobrze, sprawdź db.test_collection.find({seen_events: {$gt: ''}}).explain(true).executionStats. Prawdopodobnie można wymusić, aby widoczne zdarzenia były łańcuchami za pomocą sprawdzania poprawności schematu: docs.mongodb.com/manual/core/schema-validation
— wojcikstefan
Dzięki! Wszystkie istniejące wartości są ciągami, więc wypróbuję to. Jest też błąd omawiający ten problem w narzędziu do śledzenia
— NCode
30

Począwszy od wersji 2.6, innym sposobem na to jest porównanie pola z pustą tablicą:

ME.find({pictures: {$gt: []}})

Testowanie w powłoce:

> db.ME.insert([
{pictures: [1,2,3]},
{pictures: []},
{pictures: ['']},
{pictures: [0]},
{pictures: 1},
{foobar: 1}
])

> db.ME.find({pictures: {$gt: []}})
{ "_id": ObjectId("54d4d9ff96340090b6c1c4a7"), "pictures": [ 1, 2, 3 ] }
{ "_id": ObjectId("54d4d9ff96340090b6c1c4a9"), "pictures": [ "" ] }
{ "_id": ObjectId("54d4d9ff96340090b6c1c4aa"), "pictures": [ 0 ] }

Tak więc poprawnie obejmuje dokumenty, w których picturesznajduje się co najmniej jeden element tablicy, i wyklucza dokumenty, w których picturesjest pusta tablica, a nie tablica, lub jej brakuje.

— JohnnyHK
źródło
7
OSTROŻNIE ta odpowiedź może sprawić kłopoty, jeśli spróbujesz użyć indeksów. Wykonanie, db.ME.createIndex({ pictures: 1 })a następnie db.ME.find({pictures: {$gt: []}})zwróci zero wyników, przynajmniej w MongoDB v3.0.14
— wojcikstefan
@wojcikstefan Good catch. Musisz spojrzeć na to świeżo.
— JohnnyHK,
5

Aby to osiągnąć, możesz użyć dowolnego z poniższych.
Obie dbają również o to, aby nie zwracać wyniku dla obiektów, które nie zawierają żądanego klucza:

db.video.find({pictures: {$exists: true, $gt: {$size: 0}}})
db.video.find({comments: {$exists: true, $not: {$size: 0}}})
— Paul Imisi
źródło
4

Pobierz wszystkie i tylko dokumenty, w których „obrazy” są tablicą i nie są puste

ME.find({pictures: {$type: 'array', $ne: []}})

Jeśli używasz wersji MongoDb wcześniejszej niż 3.2 , użyj $type: 4zamiast $type: 'array'. Zauważ, że to rozwiązanie nie używa nawet $ size , więc nie ma problemu z indeksami („Zapytania nie mogą używać indeksów dla części zapytania $ size”)

Inne rozwiązania, w tym te (zaakceptowana odpowiedź):

ME.find ({zdjęcia: {$ istnieje: prawda, $ not: {$ rozmiar: 0}}}); ME.find ({zdjęcia: {$ istnieje: prawda, $ ne: []}})

są błędne , ponieważ wracają do dokumentów nawet jeśli, na przykład, „zdjęcia” jest null, undefined, 0, itd.

— SC1000
źródło
2

Użyj $elemMatchoperatora: zgodnie z dokumentacją

Operator $ elemMatch dopasowuje dokumenty zawierające pole tablicy z co najmniej jednym elementem spełniającym wszystkie określone kryteria zapytania.

$elemMatchesupewnia się, że wartość jest tablicą i że nie jest pusta. Zapytanie byłoby więc podobne

ME.find({ pictures: { $elemMatch: {$exists: true }}})

PS Wariant tego kodu znajduje się na kursie M121 Uniwersytetu MongoDB.

— Andres Moreno
źródło
0

Możesz także użyć metody pomocniczej. Istnieje nad operatorem Mongo $ istnieje

ME.find()
    .exists('pictures')
    .where('pictures').ne([])
    .sort('-created')
    .limit(10)
    .exec(function(err, results){
        ...
    });
— Jedz w Joes
źródło
0 
{ $where: "this.pictures.length > 1" }

użyj $ where i podaj this.field_name.length, które zwracają rozmiar pola tablicy i sprawdź to przez porównanie z liczbą. jeśli jakakolwiek tablica ma wartość inną niż wielkość tablicy musi wynosić co najmniej 1. więc wszystkie pola tablicy mają długość większą niż jeden, oznacza to, że zawiera pewne dane w tej tablicy

— Prabhat Yadav
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.