[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:
Related
related to SERVER-134 $unset (was: $unset and $rename) Closed
Participants:

 Description   

db.rename.insert({_id:1, a:1})
db.rename.update({_id:1}, {$rename:{'a':'b'}})
db.find({_id:1})
{_id:1, b: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: SERVER-394 implement rename modifier
http://github.com/mongodb/mongo/commit/5e538ccb8ab0d99129c3b5c9316f2b25e877d3cf

Comment by auto [ 29/Sep/10 ]

Author:

{'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}

Message: SERVER-394 bsonobjbuilder allow returning newly appended element, in one case
http://github.com/mongodb/mongo/commit/2a4c95a3f44b12968f819e77799c8b0af9434625

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:
>>

{a:[1,2,3]}


>> {$rename:{'a.1':'a.0'}}
>
>that should not be allowed (uassert)

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?
Yes - be consistent with $unset

> {a:{b:1}}
> {$rename:{'a.b':'a'}}
> does nothing

this should uassert

> {a:

{b:1,z:1}

,c:{d:1}}
> {$rename:{'a.b':'c'}}
> yields {a:

{z: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:
>

{a:[1,2,3]}


> {$rename:{'a.1':'a.0'}}

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()
> db.f.save( {a:{b:1}} );
> db.f.update( {}, {$unset:{'a.b':1}} );
> db.f.findOne()
{ "_id" : ObjectId("4ca1890dacaa360116a8ae88"), "a" : { } }
>

Do we want to be consistent with $unset?

And just so I'm clear on the parent object case:

{a:{b:1}}
{$rename:{'a.b':'a'}}
does nothing

{a:

{b:1,z:1}

,c:{d:1}}
{$rename:{'a.b':'c'}}
yields {a:

{z: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)?
>> {a:[

{b:1,c:2}

,

{b:1}

]}
>> {rename:{'a.b':'a.c''}}
>
>reaching into arrays like that should not be allowed - as its confusing given our other operators

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?
override

> What if the target sometimes exists (in an array situation)?
> {a:[

{b:1,c:2}

,

{b:1}

]}
> {rename:{'a.b':'a.c''}}

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?
> {a:{b:1}}
> {rename:{'a.b':'a''}}
> And what if the initial object is {a:{b:1,c:1}} instead?

Not allowed in either case

> What if the source is an array, but the target is not?
> {a:[

{b:1}

,

{b:2}

],c:{}}
> {rename:{'a.b','c.b'}}

Not allowed.

> What if the source is a singleton nested object?
> {a:{b:1}}
> {rename:{'a.b','c'}}
> Do we want to blow away a?

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)?
{a:[

{b:1,c:2}

,

{b:1}

]}
{rename:{'a.b':'a.c''}}

What if the target is a parent of source?
{a:{b:1}}
{rename:{'a.b':'a''}}
And what if the initial object is {a:{b:1,c:1}} instead?

What if the source is an array, but the target is not?
{a:[

{b:1}

,

{b:2}

],c:{}}
{rename:{'a.b','c.b'}}

What if the source is a singleton nested object?
{a:{b:1}}
{rename:{'a.b','c'}}
Do we want to blow away a?

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
{ $rename :

{ "a" : "z" , "b" : "y" }

}
so i think regex might be making it a bit too complex.

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
{ $rename :

{ "a.x" : "a.y" }

} }
rename every element in the array?

my feeling is yes - and if so - will be a bit more work than anticipated

Generated at Thu Feb 08 02:53:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.