Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.7.8
    • Component/s: Querying, Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Minor Change

      Description

      Update query targeting, shard key validation to support the new query operator $eq.

        Issue Links

          Activity

          Hide
          valeri.karpov Valeri Karpov (Inactive) added a comment -

          FWIW here's a js test case to make sure $eq works as expected, at least for my use case:

          db.x.insert({ x: 5 });
          db.x.find({ a: { $eq: { $gt: 4 } } }); // should return no results

          Show
          valeri.karpov Valeri Karpov (Inactive) added a comment - FWIW here's a js test case to make sure $eq works as expected, at least for my use case: db.x.insert({ x: 5 }); db.x.find({ a: { $eq: { $gt: 4 } } }); // should return no results
          Hide
          xgen-internal-githook Githook User added a comment -

          Author:

          {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

          Message: SERVER-14973 consolidate shard key parsing, cleanup shard key patterns
          Branch: master
          https://github.com/mongodb/mongo/commit/22f8b6259602a76f8d22cba8b1098f9e3c90a36f

          Show
          xgen-internal-githook Githook User added a comment - Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'} Message: SERVER-14973 consolidate shard key parsing, cleanup shard key patterns Branch: master https://github.com/mongodb/mongo/commit/22f8b6259602a76f8d22cba8b1098f9e3c90a36f
          Hide
          greg_10gen Greg Studer (Inactive) added a comment - - edited

          Author:

          {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

          Message: SERVER-13635 take ownership of shard key in shardCollection
          Branch: master
          https://github.com/mongodb/mongo/commit/28adefebaddfaabe11db7bdf73a974477bc44484

          EDIT: This commit was mistakenly attached to SERVER-13635, but properly belongs here as a bugfix for the previous commit.

          Show
          greg_10gen Greg Studer (Inactive) added a comment - - edited Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'} Message: SERVER-13635 take ownership of shard key in shardCollection Branch: master https://github.com/mongodb/mongo/commit/28adefebaddfaabe11db7bdf73a974477bc44484 EDIT: This commit was mistakenly attached to SERVER-13635 , but properly belongs here as a bugfix for the previous commit.
          Hide
          greg_10gen Greg Studer (Inactive) added a comment - - edited

          This change clarifies some edge cases in our upsert syntax, for example:

          Empty collection and running against a single mongod:

          db.coll.update({ _id : 1 }, { a : 1 }, { upsert : true });
          v2.6 and v2.8 => upserted with _id : 1
           
          db.coll.update({ _id : { $eq : 1 } }, { a : 1 }, { upsert : true });
          v2.6 => error
          v2.8 => upserted with _id : 1
           
          db.coll.update({ _id.x : 1, _id.y : 2 }, { $set : { a : 1 } }, { upsert : true });
          v2.6, v2.8 => upserted with _id : { x : 1, y : 2 }
           
          db.coll.update({ _id.x : 1, _id.y : 2 }, { a : 1 }, { upsert : true });
          v2.6 => on upsert, confusingly, a random ObjectId is generated
          v2.8 => error, must specify full _id value

          Sharded with k : 1:

          db.coll.update({ k : { $eq : 1 } }, { $set : { k : 1 } }, { upsert : true })
          2.6 => error
          2.8 => upserted with k : 1
           
          db.coll.update({ k : { $eq : 1 }, k.x : 1 }, { $set : { k : 1 } }, { upsert : true })
          v2.6 => error, update conflict at mongod
          v2.8 => error extracting shard key k

          Show
          greg_10gen Greg Studer (Inactive) added a comment - - edited This change clarifies some edge cases in our upsert syntax, for example: Empty collection and running against a single mongod : db.coll.update({ _id : 1 }, { a : 1 }, { upsert : true }); v2.6 and v2.8 => upserted with _id : 1   db.coll.update({ _id : { $eq : 1 } }, { a : 1 }, { upsert : true }); v2.6 => error v2.8 => upserted with _id : 1   db.coll.update({ _id.x : 1, _id.y : 2 }, { $set : { a : 1 } }, { upsert : true }); v2.6, v2.8 => upserted with _id : { x : 1, y : 2 }   db.coll.update({ _id.x : 1, _id.y : 2 }, { a : 1 }, { upsert : true }); v2.6 => on upsert, confusingly, a random ObjectId is generated v2.8 => error, must specify full _id value Sharded with k : 1: db.coll.update({ k : { $eq : 1 } }, { $set : { k : 1 } }, { upsert : true }) 2.6 => error 2.8 => upserted with k : 1   db.coll.update({ k : { $eq : 1 }, k.x : 1 }, { $set : { k : 1 } }, { upsert : true }) v2.6 => error, update conflict at mongod v2.8 => error extracting shard key k

            People

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

              Dates

              • Created:
                Updated:
                Resolved: