Uploaded image for project: 'PHP Legacy Driver'
  1. PHP Legacy Driver
  2. PHP-1051

"$in needs an array" error when running find() against MongoDB 2.6

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: pecl-mongo
    • Labels:
    • # Replies:
      10
    • Last comment by Customer:
      false

      Description

      This works in mongodb 2.4.9, but not in 2.6.0-rc2:

      $a = array('_id' => array( '$in' => array_values($ids) ) ); 
      var_dump($a);
      $cursor2 = $data->find( $a );

      returns:

      Type: MongoCursorException
      Code: 17287
      Message: Can't canonicalize query: BadValue $in needs an array

      Output from var_dump:

      array(1) {
        ["_id"]=>
        array(1) {
          ["$in"]=>
          array(3) {
            [0]=>
            object(MongoId)#57 (1) {
              ["$id"]=>
              string(24) "52214d60012f8aab278eacb6"
            }
            [1]=>
            object(MongoId)#58 (1) {
              ["$id"]=>
              string(24) "52214d60012f8aab278eaca8"
            }
            [2]=>
            object(MongoId)#59 (1) {
              ["$id"]=>
              string(24) "52214d60012f8aab278eaca7"
            }
         }
      }
      }

      Apologize right away if this is a php driver bug, I wasn't sure what causes this issue.

      Thank you!

        Issue Links

          Activity

          Hide
          rookie7799 Pavel Baranov added a comment -

          I think I see what the problem is, it should be:

          ... query: { _id: { $in: [ ObjectId('52214d60012f8aab278eaad1') ...

          but for some reason it's an object because it starts like ... { 0: ...

          Show
          rookie7799 Pavel Baranov added a comment - I think I see what the problem is, it should be: ... query: { _id: { $in: [ ObjectId('52214d60012f8aab278eaad1') ... but for some reason it's an object because it starts like ... { 0: ...
          Hide
          rookie7799 Pavel Baranov added a comment -

          Yes, that's pretty much it, added array_values to all the places where I use $ids and it started working. I'm guess Mongo 2.4.9 is more lenient to the fact that $ids can be either object or an array?

          Thank you! Consider this closed.

          Show
          rookie7799 Pavel Baranov added a comment - Yes, that's pretty much it, added array_values to all the places where I use $ids and it started working. I'm guess Mongo 2.4.9 is more lenient to the fact that $ids can be either object or an array? Thank you! Consider this closed.
          Hide
          rassi J Rassi added a comment -

          The BSON serializer in the PHP driver will encode an array with the "BSON array" type if its keys are consecutive integers starting from zero (i.e. 0,1,2,3,4...). If you take the result of array_values() and remove elements from it, then it will instead be encoded with the "BSON object" type. See PHP-104. MongoDB 2.6 introduces stricter validation to the $in operator: values for $in that are not of BSON array type are rejected.

          Assuming you are indeed using unset() or equivalent, I'd classify this issue as a dup of PHP-104. You're encountering it all of a sudden now because of stricter validation that was introduced in the server, but fundamentally it stems from the design of the PHP driver API. Instead of adding more calls to array_values(), you could instead take the recommendation in PHP-104 and just remove elements with array_splice() instead.

          Show
          rassi J Rassi added a comment - The BSON serializer in the PHP driver will encode an array with the "BSON array" type if its keys are consecutive integers starting from zero (i.e. 0,1,2,3,4...). If you take the result of array_values() and remove elements from it, then it will instead be encoded with the "BSON object" type. See PHP-104 . MongoDB 2.6 introduces stricter validation to the $in operator: values for $in that are not of BSON array type are rejected. Assuming you are indeed using unset() or equivalent, I'd classify this issue as a dup of PHP-104 . You're encountering it all of a sudden now because of stricter validation that was introduced in the server, but fundamentally it stems from the design of the PHP driver API. Instead of adding more calls to array_values(), you could instead take the recommendation in PHP-104 and just remove elements with array_splice() instead.
          Hide
          rassi J Rassi added a comment -

          Moving from SERVER project => PHP project, resolving as a dup of PHP-104.

          Show
          rassi J Rassi added a comment - Moving from SERVER project => PHP project, resolving as a dup of PHP-104 .
          Hide
          jmikola Jeremy Mikola added a comment -

          [~rassi@10gen.com]: Thanks for fielding this. I can confirm that it's not a bug – more of a quirk. And we're stuck in this position if we want to continue allowing users to use associative arrays as BSON objects.

          I solve this in Doctrine ODM by ensuring values are real arrays to comply to server strictness checks (there were several patches I made for 2.6 compatibility). In the case of $in, Doctrine actually does use array_values() IIRC to ensure we don't inadvertently send an associative array over as a BSON object.

          Show
          jmikola Jeremy Mikola added a comment - [~rassi@10gen.com] : Thanks for fielding this. I can confirm that it's not a bug – more of a quirk. And we're stuck in this position if we want to continue allowing users to use associative arrays as BSON objects. I solve this in Doctrine ODM by ensuring values are real arrays to comply to server strictness checks (there were several patches I made for 2.6 compatibility). In the case of $in , Doctrine actually does use array_values() IIRC to ensure we don't inadvertently send an associative array over as a BSON object.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                3 years, 7 weeks, 6 days ago
                Date of 1st Reply: