[SERVER-4131] Allow _id-keyed single document update for collections not sharded on _id Created: 24/Oct/11  Updated: 11/Jul/16  Resolved: 06/Mar/14

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Richard Kreuter (Inactive) Assignee: Unassigned
Resolution: Done Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Participants:

 Description   

At present, we don't allow non-multi updates (single-document updates) on a sharded collection unless the query argument to update includes the shard key, (presumably because doing so would be non-deterministic, or something).

It would be handy for some applications to relax this restriction to permit updates where the query argument to the update includes a constant-valued _id parameter, even if the shard key were missing or incomplete in the query.



 Comments   
Comment by Greg Studer [ 06/Mar/14 ]

We've been doing this at least since 2.2.

Comment by Richard Kreuter (Inactive) [ 10/May/12 ]

And, in the case where the first argument to the update doesn't incorporate the shard key in a useful way or at all, we could do the single-document update on each shard at a time until one of them succeeds or we run out of shards.

Comment by Richard Kreuter (Inactive) [ 10/May/12 ]

While I'm thinking about it, non-multi updates that key on certain patterns of the leftmost subfields of a compound shard key should be deterministically routable, too. Offhand, it seems that if the shard key is

{ f0 : 1, f1 : 1, f2 : 1, ... fN : 1 }

and if (a) the first argument to update contains every field from f0 up to fJ for J < N, and (b) for every field in f0 up to f(J-1), the value being matched is constant, and (c) either fJ is constant or a range, then the update can be routed to whatever chunk contain a suitable range of shard key values.

For example, if db.foo is sharded on

{a : 1, b: 1}

, the following updates should all be routable:

db.foo.update({ a :

{ $gt : <c> }

}); // could route to highest chunk whose lower bound on a is lte <c>
db.foo.update({ a :

{ $lt : <c> }

}); // could route to lowest chunk whose upper bound on a is gte <c>
db.foo.update({ a :

{ $gt : <c1> , $lt : <c2> }

}); // could do either of the previous 2 options

db.foo.update({ a : <c> , b :

{ $gt : <d> }

}); // could route to highest chunk where <c> falls into the range for a and
// the lower bound for b is lte <d>, etc.

Comment by Richard Kreuter (Inactive) [ 10/May/12 ]

Along the same lines, findAndModify would be handier if it supported the same functionality.

Generated at Thu Feb 08 03:05:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.