[SERVER-6566] Support conditional updates: $updates Created: 23/Jul/12 Updated: 06/Dec/22 Resolved: 29/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Do | Votes: | 36 |
| Labels: | positional-operator, transactions | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Add support for multiple conditional updates in a single update operation. An array of match + update will be executed against each found document. All positional matching is done on the update match, not the query. See below for examples.
The server would execute the query, run through each conditional update element in the array (in order) and apply the update only if the match succeeds for the document. |
| Comments |
| Comment by Asya Kamsky [ 03/Jul/19 ] | |||||||||||||||||||
|
Unfortunately with current syntax the only way to do that is to create an embedded object and then in the next stage move it to top level which may be a bit unwieldy.
Can you give an example you have in mind - we would like to add simpler syntax for such cases and this way we can make sure it accommodates the use case.
| |||||||||||||||||||
| Comment by Nithin Huliyappa [ 01/Jul/19 ] | |||||||||||||||||||
|
@asya can we update more then one fields using the if-else condition only once? If "No" we need to use the same condition for every field update. | |||||||||||||||||||
| Comment by Asya Kamsky [ 29/Jun/19 ] | |||||||||||||||||||
|
You can see some examples here. I believe this can handle all of the examples/use cases that were mentioned in the comments.
| |||||||||||||||||||
| Comment by Ewgenij Gawrilow [ 23/Nov/18 ] | |||||||||||||||||||
|
A bulkWrite always executes all its parts, while the request here is to perform just one operation, corresponding to the first met criterion, and to skip the rest. How bulkWrite can help then?
| |||||||||||||||||||
| Comment by NOVALUE Mitar [ 03/Sep/18 ] | |||||||||||||||||||
|
Would bulkWrite available since MongoDB 3.2 help here? | |||||||||||||||||||
| Comment by Eli Revach [ 25/Sep/17 ] | |||||||||||||||||||
|
We find this enhancement very useful for one of our production use cases . Using this enhancement we can calculate HASH based (before the update) on the incoming event and update mongo only if the HASH we calculate is different that what is already stored in mongo (We can't simply filter the HASH on the update filter as it will create new records when no match ) | |||||||||||||||||||
| Comment by Glenn Maynard [ 05/Mar/15 ] | |||||||||||||||||||
|
That's incorrect. This is building directly on the fundamental concept that Mongo is built on- Stored procedures are a different beast entirely. This is just a list of queries and updates, not a programming language. | |||||||||||||||||||
| Comment by Christoph Menge [ 05/Mar/15 ] | |||||||||||||||||||
|
I think that moving too much logic into the database or in database-related code is the root of all evil. I might have an extreme opinion, but the path of stored procedures and super-duper complex query and update statements for me is a key reason to refrain from SQL. If I write my program in Java, I want the business logic in Java, not in some kind of wicked DSL that was created iteratively. Introducing control-flow statements like $when and $do makes it a full-blown language, with all strings attached. | |||||||||||||||||||
| Comment by srinivasa somepalli [ 07/Feb/15 ] | |||||||||||||||||||
|
@Arnaldo. sure can. | |||||||||||||||||||
| Comment by Pierre Le Roux [ 15/Sep/14 ] | |||||||||||||||||||
|
I would be very happy to see Glenn Maynard purposes in next Mongodb release. So a big +1 for me ! | |||||||||||||||||||
| Comment by Arnaldo Capo [ 15/Jul/14 ] | |||||||||||||||||||
|
I think this feature will make save lives. | |||||||||||||||||||
| Comment by Glenn Maynard [ 05/Feb/14 ] | |||||||||||||||||||
|
This would be a big improvement. It will allow doing server-side, atomic updates in a single round trip, which are currently impossible without layering in a lot of extra complexity and making extra round trips. It solves a lot of problems with one straightforward vocabulary. Just rename "when" to $when and "do" to $do, to avoid ambiguity and avoid the JS keyword. It would avoid more weirdness like $push's $slice sub-modifier. $slice could have just been a simple, standalone operator. It also reduces the need to add more special-case modifiers; for example, $min, $max and $addToSet would all be unnecessary. Mixing $updates with other modifiers should be disallowed. There's no reason to say { $set: {}, $updates: [] } (just put the $set in the array), and the order of operations would be unclear. I'd recommend just using an array directly instead of a modifier. For example:
It would also help findAndModify. Currently, it's not possible to use findAndModify to read a record, modify it if a condition holds, and return the final document whether or not it was modified. For example, to update a user's top_score and top_score_date, and atomically retrieve the best score regardless of whether the new score was better or not:
| |||||||||||||||||||
| Comment by David Pfeffer [ 08/Sep/13 ] | |||||||||||||||||||
|
This is a feature that is sorely lacking in Mongo. We have to do > 25 queries in some cases to work around the problem. |