|
While these points are true, meaning this behaviour is technically possible/correct, I don't think it's actually desirable.
The main problem is that the runnability of these ops would depend on the current chunk layout, which is fluid and changes transparently. Ops which depend on unseen state will thus be fragile, and so such dependencies should be avoided.
It's no good being able to run
db.test.update( { _id: { $ge: 1, $le: 3 } }, { ... }, { upsert: true } )
|
if it fails 5 minutes later because a chunk with range 2 to 4 has been migrated to another shard. In fact it can be worse to allow this to succeed when possible, precisely because there's no guarantee it'll always work. Developers will see these ops work in simple cases, code them into their app, and then be frustrated when one day they suddenly stop working in production for no apparent reason ("nothing changed"). This is the real reason for the exact shard key value match constraint, even though from some angles it looks overly restrictive.
|