[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: |
|
||||||||
| 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> }); // could route to lowest chunk whose upper bound on a is gte <c> }); // 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 |
| Comment by Richard Kreuter (Inactive) [ 10/May/12 ] |
|
Along the same lines, findAndModify would be handier if it supported the same functionality. |