[SERVER-29612] Permit $rename with identical source and destination Created: 13/Jun/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Querying, Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Justin Seyster | 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 |
|
The current implementation of $rename prohibits any rename with an identical source and destination path but includes a TODO noting that we could instead treat this operation as a no-op. If we do want to make that change, now would be a good time, as we are making backwards-incompatible changes to update functionality. |
| Comments |
| Comment by Justin Seyster [ 01/Jul/19 ] |
|
asya I agree that the only use case I can think of would be some kind of autogenerated update. I haven't heard anything from in field about wanting to do no-op renames, so our primary motivation to do this would be to simplify update semantics by removing an edge case. Mostly, I think of this ticket as something to keep in mind every time we revisit $rename semantics. |
| Comment by Asya Kamsky [ 29/Jun/19 ] |
|
What's the use case to allow it? Have you heard of it ever causing an issue in the field? I can only imagine it might if the update with $rename was autogenerated in some way that caused this rename of a to a... |