[SERVER-13478] Resolve ambiguity of positional array updates when the path does not exist Created: 03/Apr/14 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Gerry F | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | mql-semantics | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
The upsert behaviour in update does not handle arrays the same way for insert and update. Upsert is only useful in the case that you don't know if the object already exists. I need a way to call upsert with arrays that creates the same document shape for both insert and update. This will allow efficient manipulation of array contents. The example below is a simple demonstration of the problem, using the mongo shell. Simplest version, mongo shell code. The first upsert adds to the 'arr' array, the second creates an 'arr' document, the third creates an 'arr' array.
Slightly more complex version.
|
| Comments |
| Comment by Andrei Stepanov [ 09/Jul/21 ] | |||
|
@asya, could you please give an example hot to `getting around this ambiguity` for the example that stays in this question:
That it creates an array. Thank you. | |||
| Comment by Asya Kamsky [ 11/Sep/19 ] | |||
|
I believe in 4.2 the ability to express update portion using aggregation syntax allows getting around this ambiguity. You can see examples in this comment and in the docs
| |||
| Comment by David Storch [ 20/Feb/18 ] | |||
|
asya, yep, done. | |||
| Comment by Asya Kamsky [ 15/Feb/18 ] | |||
|
david.storch this should probably be linked to language semantics or array syntax epic? | |||
| Comment by David Storch [ 03/Feb/16 ] | |||
|
Hi GerryF, Thanks for filing this ticket. This looks like an unfortunate consequence of the semantics of a $set with a numerical path component. Consider the following example:
The resulting document is { "_id" : 1, "a" : { "1" : "foo" } }. The update system does not consider numerical path components to have special array semantics unless there is an existing array along the update path. Note that the application of the update modifiers when {upsert: true} results in an insert is identical to the application of modifiers when a matching document is found (both in terms of semantics and implementation). I don't think we can safely change the semantics of the update language, so to resolve this problem we may have to create a syntax that is specific to position-based array updates. For instance, we could introduce syntax like {$set: {"a.$3": "foo"}} which unambiguously means
I am keeping this ticket open in order to represent a feature request of this nature. Best, |