Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-13963

Different Results from nested array query

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 2.6.0, 2.6.1
    • Component/s: Querying
    • None
    • ALL
    • Hide

      The following issue was raised on Stack Overflow in this question.

      The data has been set up like this:

      db.posts.insert({sents:
          [
              {uni:['a','b','c'],bi:[['a','b'],['b','c']]},
              {uni:['x','y','z'],bi:[['x','y'],['y','z']]}
          ]})
      
      

      The following query when issued in 2.4 versions returns the desired result:

      db.posts.find({'sents.bi':{'$elemMatch':{'$in':['a']}}})
      

      and result:

      { 
          "_id" : ObjectId("537595f254bae6dfabddf0c9"), 
           "sents" : [     
               { 
                   "uni": [ "a", "b", "c" ],
                   "bi": [[ "a", "b" ],  [ "b", "c" ] ] 
               },
               {
                   "uni": [ "x", "y", "z" ],  
                   "bi": [ [ "x",    "y" ],  [ "y", "z" ] ] 
               } 
           ] 
      }
      

      The same query issued in 2.6 does not return any result.

      This is questionable as I believe the correct form of the query should be:

      db.posts.find({'sents.bi':{'$elemMatch': {$elemMatch: {$in: ['a']}}}})
      

      Which will return the desired result in both versions.

      So not sure if the selection is a bug that was present in earlier releases or whether there is something causing that statement to fail in 2.6 releases.

      As a side note the question itself refers to creating an index on the collection:

      db.posts.ensureIndex({ 'sents.bi'})
      

      Which causes the query to fail in earlier versions. This I believe to be correct due to the nested array than cannot be used as in index value.

      The second form of the query will not directly select an index unless that has been hinted in some way.

      In 2.6 a hint to that index will produce an error and a sort simply ignores the index. In 2.4 the index will be shown as selected in the explain output, but there will be no bounds selected.

      Show
      The following issue was raised on Stack Overflow in this question. The data has been set up like this: db.posts.insert({sents: [ {uni:[ 'a' , 'b' , 'c' ],bi:[[ 'a' , 'b' ],[ 'b' , 'c' ]]}, {uni:[ 'x' , 'y' , 'z' ],bi:[[ 'x' , 'y' ],[ 'y' , 'z' ]]} ]}) The following query when issued in 2.4 versions returns the desired result: db.posts.find({ 'sents.bi' :{ '$elemMatch' :{ '$ in ' :[ 'a' ]}}}) and result: { "_id" : ObjectId( "537595f254bae6dfabddf0c9" ), "sents" : [ { "uni" : [ "a" , "b" , "c" ], "bi" : [[ "a" , "b" ], [ "b" , "c" ] ] }, { "uni" : [ "x" , "y" , "z" ], "bi" : [ [ "x" , "y" ], [ "y" , "z" ] ] } ] } The same query issued in 2.6 does not return any result. This is questionable as I believe the correct form of the query should be: db.posts.find({ 'sents.bi' :{ '$elemMatch' : {$elemMatch: {$ in : [ 'a' ]}}}}) Which will return the desired result in both versions. So not sure if the selection is a bug that was present in earlier releases or whether there is something causing that statement to fail in 2.6 releases. As a side note the question itself refers to creating an index on the collection: db.posts.ensureIndex({ 'sents.bi' }) Which causes the query to fail in earlier versions. This I believe to be correct due to the nested array than cannot be used as in index value. The second form of the query will not directly select an index unless that has been hinted in some way. In 2.6 a hint to that index will produce an error and a sort simply ignores the index. In 2.4 the index will be shown as selected in the explain output, but there will be no bounds selected.

      Querying elements within a nested array structure works differently in 2.6 releases than it does in prior 2.4 releases

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            neillunn Neil Lunn
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: