[SERVER-76926] Unify insert and {upsert: true} insert behavior for $setOnInsert: Timestamp(0,0) Created: 08/May/23 Updated: 11/Aug/23 Resolved: 14/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sanika Phanse (Inactive) | Assignee: | Backlog - Query Execution |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Execution
|
||||
| Participants: | |||||
| Description |
|
Upon inserting a document with { $setOnInsert { 'a' : Timestamp(0,0) }, the timestamp is overwritten to reflect the operational timestamp here. However, an update with {upsert: true}that specifies $setOnInsert { 'a' : Timestamp(0,0) }preserves the value Timestamp(0,0) in the upserted document. This is inconsistent behavior between two types of inserts. I would recommend unifying this behavior. This ticket is relevant for the updateOneWithoutShardKey project as upserts are converted to inserts on mongos. So, while the user behavior would've originally expected Timestamp(0,0) to remain, it now reflects the operational timestamp. |
| Comments |
| Comment by Rohan Sharan [ 11/Aug/23 ] |
|
How difficult would this be to fix? We're seeing inconsistencies in mongosync because of this. It would not be ideal to add a limitation that mongosync can't support syncing documents with a field of timestamp(0, 0). |
| Comment by Kyle Suarez [ 14/Jun/23 ] |
|
After in a discussion in the Query Execution triage meeting, while we acknowledge this is an inconsistency in behavior, we don't think that this is worth fixing because it represents a corner case that almost no customer is going to encounter in practice. We're going to close this issue unless there's any actual customer impact. |