[SERVER-394] $rename updates Created: 28/Oct/09 Updated: 12/Jul/16 Resolved: 30/Sep/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | 1.7.2 |
| Type: | New Feature | Priority: | Minor - P4 |
| Reporter: | Mathias Stearn | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 28 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
db.rename.insert({_id:1, a:1}) oplog needs to be rewritten as $unset/$set or a op in the middle could cause problems |
| Comments |
| Comment by Aaron Staple [ 04/Oct/10 ] |
|
added doc |
| Comment by auto [ 29/Sep/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by auto [ 29/Sep/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
It looks like for other operators we just uassert if we see a non conforming document, so I guess I'll do that too. (And possibly subsequent valid documents will not get the mod but earlier ones will - haven't looked closely enough). |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
Ok, but what if the update applies to multiple documents {a:{'0':1}} {a:[1]}{$rename:{'a.0':'a.1'}} At what point would we uassert? |
| Comment by Eliot Horowitz (Inactive) [ 28/Sep/10 ] |
|
We should uassert it if its an array |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
>> Also, I know we're not supposed to reach into arrays - but what if someone wants to rename one array index to another: I believe we're allowed to have objects with field names consisting entirely of digits. If we uassert in this case, won't it prevent folks from renaming those fields? |
| Comment by Eliot Horowitz (Inactive) [ 28/Sep/10 ] |
|
> Do we want to be consistent with $unset? > {a:{b:1}} this should uassert > {a: {b:1,z:1},c:{d:1}} ,{c:1}} correct > Also, I know we're not supposed to reach into arrays - but what if someone wants to rename one array index to another: that should not be allowed (uassert) > Also, can _id be source or target of a rename? No - that should uassert |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
Also, can _id be source or target of a rename? |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
Also, I know we're not supposed to reach into arrays - but what if someone wants to rename one array index to another: {a:[1,2,3]}{$rename: {'a.1':'a.0'}} |
| Comment by Aaron Staple [ 28/Sep/10 ] |
|
It looks like with $unset, in the singleton nested case I described above the parent object is retained: > db.f.remove() Do we want to be consistent with $unset? And just so I'm clear on the parent object case: {a:{b:1}} {a: {b:1,z:1},c:{d:1}} ,{c:1}} Is that what you want? |
| Comment by Eliot Horowitz (Inactive) [ 28/Sep/10 ] |
|
Yeah - lets not allow that for now and see if it comes up |
| Comment by Aaron Staple [ 27/Sep/10 ] |
|
>> What if the target sometimes exists (in an array situation)? , {b:1}]} Ok - I just want to confirm that this is the desired behavior, as reaching into an array is described in the first comment of this jira. |
| Comment by Eliot Horowitz (Inactive) [ 27/Sep/10 ] |
|
> What if the target exists - is it an error or an overwrite? > What if the target sometimes exists (in an array situation)? , {b:1}]} reaching into arrays like that should not be allowed - as its confusing given our other operators > What if the target is a parent of source? Not allowed in either case > What if the source is an array, but the target is not? , {b:2}],c:{}} Not allowed. > What if the source is a singleton nested object? blow away IF a is empty after rename the other thing to be careful with is replica idempotentcy. should convert to $unset and $set probably |
| Comment by Aaron Staple [ 27/Sep/10 ] |
|
As I get started I want to ask about desired behavior in a few random corner cases: What if the target exists - is it an error or an overwrite? What if the target sometimes exists (in an array situation)? , {b:1}]} What if the target is a parent of source? What if the source is an array, but the target is not? , {b:2}],c:{}} What if the source is a singleton nested object? We can eliminate some of these questions if we restrict allowed renamings, but I didn't want to assume we would do this. |
| Comment by Eliot Horowitz (Inactive) [ 09/Aug/10 ] |
|
I don't think $rename itself should change indexes. Another command to do a full rename would be good. |
| Comment by Mathias Stearn [ 09/Aug/10 ] |
|
We should probably have a command to do full renaming of fields including indexes. Since update can work on a subset of the objects in a collection, it probably doesn't make sense to do that in update. |
| Comment by Aaron Staple [ 09/Aug/10 ] |
|
should the index keys get renamed too? |
| Comment by Eliot Horowitz (Inactive) [ 24/Apr/10 ] |
|
You'll be able to do multiple already } |
| Comment by Scott Hernandez (Inactive) [ 24/Apr/10 ] |
|
What if I want to rename a set of keys (using a regex to select them)? I was thinking it would take a regex to match the keys and optionally one for the new key names (based on the orig key name regex matches). Thinking about it more I think it would require some kind of expression system to format the new names (based on the regex matches). Does that make more sense? |
| Comment by Eliot Horowitz (Inactive) [ 26/Mar/10 ] |
|
regex support? I don't think so - but not even sure I understand what it would be. |
| Comment by Scott Hernandez (Inactive) [ 26/Mar/10 ] |
|
With regex support? |
| Comment by Michael Dirolf [ 15/Mar/10 ] |
|
yes I think so |
| Comment by Eliot Horowitz (Inactive) [ 15/Mar/10 ] |
|
anyone have thoughts on { a : [ { x : 2 }, { x : 3 }] } should } } my feeling is yes - and if so - will be a bit more work than anticipated |