[SERVER-48397] Make collMod no-op behaviour consistent Created: 25/May/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
As of However, the same is not currently true of the expireAfterSeconds field. If the user attempts to set this to the same value it already has, then the corresponding oplog entry will redundantly include the expireAfterSeconds field, and the command response will explicitly list the (identical) old and new values of the parameter. We should decide which behaviour we want, both in terms of the oplog entry and the command response, and make sure that both fields are handled consistently. This may involve pushing the no-op detection down to the replication system here. |
| Comments |
| Comment by Bernard Gorman [ 26/May/20 ] | |||||||||||||||||
|
daniel.gottlieb, judah.schvimer, for clarity: we do still generate an oplog entry if collMod's hidden value is a "no-op", i.e. the same as the existing value. But this oplog entry does not contain the hidden field - it is effectively the same as if the user had issued an empty collMod command.
| |||||||||||||||||
| Comment by Judah Schvimer [ 26/May/20 ] | |||||||||||||||||
|
collmod should be able to accept a write concern.
All commands are expected to buy into "noop writes still wait for write concern". collmod should have this behavior. If we have any concern though, we should test this. It doesn't look like we already have a test. | |||||||||||||||||
| Comment by Daniel Gottlieb (Inactive) [ 26/May/20 ] | |||||||||||||||||
|
Not necessarily related, but this ticket mentioned two keywords (no-op and user) that trigger me to communicate some subtle, but intended MongoDB behavior. Apologies if I've assumed the ticket is going somewhere that it's not. Can collmod accept a write concern (e.g: "majority")? One of behavior's we've converged on (with "normal" updates) is not assuming a no-op update means the intended update has satisfied its write concern. Consider the following:
Even though the second update is a no-op (in the oplog), we have code that makes sure the response doesn't return to the client until the version of the document that was read is guaranteed to be majority committed. I'm not familiar enough to know whether all of commands buy into this, or if they each have to instrument the logic. |