[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:
Related
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...

Generated at Thu Feb 08 04:21:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.