Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-3180

Suggestion for /master/reference/operator/query/or/



    • Type: Improvement
    • Status: Closed
    • Priority: Minor - P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: v1.3.5
    • Component/s: manual
    • Labels:
    • # Replies:
    • Last comment by Customer:
    • Actual Time:


      "New in version 1.6."

      This is a huge pythonism. 5(?)years later, this is still touted as a brand new feature.

      • The version number should be link to the release notes
      • Was it 1.6 or 2.6 that was just released? Or 3.6? Can I safely use this feature?
        • Takes up way to much precious screen real-estate for no gain
        • We don't maintain multiple major branches so why do I care it was added before current stable major release?
      • Why are the documents both versioned and changes kept inline? pick one.

      How inefficient is nested $or (which is the second everybody-must-know about this feature - and you need to know it was added in 2.0).

      This modified query will not use the index on price nor the index on sale.

      Why not? How do I make it? Does it use any index?

      The example "document" is also weird.
      The inventory contains a mix of items and already sold items?
      Is it really good practice to create an index on a boolean field?
      Is 'quantity' to long fieldname so we have to use 'qty'?

      If $or includes a $text query, all clauses in the $or array must be indexed.

      Does it have to be the same index? Can the index be of different type? Why is $text so special?




            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created:
                Days since reply:
                5 years, 40 weeks ago
                Date of 1st Reply: