Core Server
  1. Core Server
  2. SERVER-267

Wildcard support in index/query/projection=

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major - P3 Major - P3
    • Resolution: Unresolved
    • Affects Version/s: 0.9.9
    • Fix Version/s: Planning Bucket C
    • Component/s: Indexing, Querying
    • Labels:
      None
    • # Replies:
      5
    • Last comment by Customer:
      true

      Description

      db.foo.ensureIndex(

      { "a.*.b" : 1 }

      )
      db.foo.find(

      { "a.*.b" : 5 }

      )
      db.foo.find( {} ,

      { "a.*b" : 1 }

      )

        Issue Links

          Activity

          Hide
          Mike Harris
          added a comment -

          This is not complete at all, still many things to work on, but I have the beginnings of a patch here

          http://github.com/mharris717/mongo/commit/b27d8577a7c0bec037e5b0939f20bbf0e1b14337

          Passes the basic test cases

          Show
          Mike Harris
          added a comment - This is not complete at all, still many things to work on, but I have the beginnings of a patch here http://github.com/mharris717/mongo/commit/b27d8577a7c0bec037e5b0939f20bbf0e1b14337 Passes the basic test cases
          Hide
          Bradford Smith
          added a comment -

          As a beginner MongoDB user, I had no idea that there was no support for this. Consequently, I modeled my data as follows:

          {
          "_id" : "store1",
          "name": "Store 1",
          "notes" : {
          "4d221860edc6ae20218cc50a" :

          { "text" : "aaa", "hide" : false }

          ,
          "4d221860edc6ae20218cc50b" :

          { "text" : "bbb", "hide" : true }

          ,
          "4d221860edc6ae20218cc50c" :

          { "text" : "ccc", "hide" : true }

          }
          }

          The reason for this is because I have an admin screen to edit notes and the URL is something like /editNotes?id=4d221860edc6ae20218cc50c

          db.stores.find({'notes.4d221860edc6ae20218cc50c': {$exists: true}})

          This allows me to get the store document containing that note. And since I treat notes as Map<ObjectId, Notes> notes, I can then just do notes.get("4d221860edc6ae20218cc50c"); to get the notes for 4d221860edc6ae20218cc50c. The problem is it's really hard to maintain this. For example, let's say I want to set all notes to hide = false. How would I do this? I also had a related question in SERVER-2238.

          Show
          Bradford Smith
          added a comment - As a beginner MongoDB user, I had no idea that there was no support for this. Consequently, I modeled my data as follows: { "_id" : "store1", "name": "Store 1", "notes" : { "4d221860edc6ae20218cc50a" : { "text" : "aaa", "hide" : false } , "4d221860edc6ae20218cc50b" : { "text" : "bbb", "hide" : true } , "4d221860edc6ae20218cc50c" : { "text" : "ccc", "hide" : true } } } The reason for this is because I have an admin screen to edit notes and the URL is something like /editNotes?id=4d221860edc6ae20218cc50c db.stores.find({'notes.4d221860edc6ae20218cc50c': {$exists: true}}) This allows me to get the store document containing that note. And since I treat notes as Map<ObjectId, Notes> notes, I can then just do notes.get("4d221860edc6ae20218cc50c"); to get the notes for 4d221860edc6ae20218cc50c. The problem is it's really hard to maintain this. For example, let's say I want to set all notes to hide = false. How would I do this? I also had a related question in SERVER-2238 .
          Hide
          Israel Alvarez
          added a comment -

          Would also like to have this feature. Or even better, something like $elemMatch query operator that works on keys instead of values.

          Show
          Israel Alvarez
          added a comment - Would also like to have this feature. Or even better, something like $elemMatch query operator that works on keys instead of values.
          Hide
          Nick Del Regno
          added a comment - - edited

          I would also like to have this feature.

          I developed a schema for my current project, but then had to rework based on the inability to query using wildcard subkeys. For example:

          {
          "_id" : "NY50_A",
          "ports" : {
          "1/1/1" :

          { "description" : "TRK to NYBR_B", "state" : "no shutdown"}

          ,
          "1/1/2" :

          { "description" : "PND to NY50_B", "state" : "shutdown"}

          ,
          etc...
          }
          }

          I'd like to be able to query using db.collection.find(

          {"ports.$.state" : "no shutdown"}

          , {_id:1, ports:1}). This would return all of the ports, in all switches, which are shutdown.

          In lieu of this functionality, I am reevaluating my schema to determine how I can achieve the same effect without having to issue discrete finds for

          {"ports.1/1/1.state" : "no shutdown"}

          and

          {"ports.1/1/2.state" : "no shutdown"}

          , etc, since each switch will have different card/port configurations.

          Show
          Nick Del Regno
          added a comment - - edited I would also like to have this feature. I developed a schema for my current project, but then had to rework based on the inability to query using wildcard subkeys. For example: { "_id" : "NY50_A", "ports" : { "1/1/1" : { "description" : "TRK to NYBR_B", "state" : "no shutdown"} , "1/1/2" : { "description" : "PND to NY50_B", "state" : "shutdown"} , etc... } } I'd like to be able to query using db.collection.find( {"ports.$.state" : "no shutdown"} , {_id:1, ports:1}). This would return all of the ports, in all switches, which are shutdown. In lieu of this functionality, I am reevaluating my schema to determine how I can achieve the same effect without having to issue discrete finds for {"ports.1/1/1.state" : "no shutdown"} and {"ports.1/1/2.state" : "no shutdown"} , etc, since each switch will have different card/port configurations.
          Hide
          Glenn Maynard
          added a comment -

          I've needed to do this before, due to MongoDB's limitations with handling arrays. I think that rather than supporting these queries, it'd be better to fix the limitations of arrays. After all, even if Mongo supports wildcard key queries, there would still be other things you couldn't do with dictionary values, like aggregation. Instead of enhancing dictionaries to let them do things we can already do with arrays (creating a lot of duplication of functionality in the process), enhance arrays so we don't need to use dictionaries like this in the first place.

          SERVER-6566 would fix all of the cases I've seen.

          Show
          Glenn Maynard
          added a comment - I've needed to do this before, due to MongoDB's limitations with handling arrays. I think that rather than supporting these queries, it'd be better to fix the limitations of arrays. After all, even if Mongo supports wildcard key queries, there would still be other things you couldn't do with dictionary values, like aggregation. Instead of enhancing dictionaries to let them do things we can already do with arrays (creating a lot of duplication of functionality in the process), enhance arrays so we don't need to use dictionaries like this in the first place. SERVER-6566 would fix all of the cases I've seen.

            People

            • Votes:
              40 Vote for this issue
              Watchers:
              35 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since reply:
                11 weeks ago
                Date of 1st Reply: