[SERVER-23239] $move operator for moving a value somewhere else in the same document Created: 18/Mar/16  Updated: 06/Dec/22  Resolved: 29/Jun/19

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Billy Tetrud Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Do Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Participants:

 Description   

Three cases:

  • Move and overwrite: say moving property 'a.b.c' to 'x.y.z'
  • Multiple move, last overwrite: say moving property a to b, property b to c, property c to d overwriting d
  • Move to insert in array: say moving property x to 'a.3', shifting up all current elements from 3 onward. If the value being moved to is from an array, shift down that array.

Currently all of these cases can require potentially large amounts of data to be passed back and forth, when the server really has all that information already.



 Comments   
Comment by Charlie Swanson [ 26/Jul/19 ]

HappyNomad I responded on your StackOverflow post.

Comment by Adrian Pinter [ 26/Jul/19 ]

How could one use 4.2's aggregation expressions to specify an update that moves a nested object between arrays?  I asked this question here and here. I could use an example that specifically demonstrates this.

Comment by Asya Kamsky [ 29/Jun/19 ]

SERVER-40381 implemented support for aggregation expressions to specify update for 4.2. 

You can see some examples here.

This can be done using aggregation expressions.

Comment by Billy Tetrud [ 21/Mar/16 ]

Ah, yes. Well I think both are important. Looking at the $rename docs, I believe "replace the element currently at a.3 with x" can already be done with $rename. The former, "move x to a.3 shifting all elements from a.3 onward up by one index" can't currently be done with any existing command. That's the one I'm primarily interested in.

Comment by Andy Schwerin [ 21/Mar/16 ]

Sorry, my point wasn't that your suggestion was invalid. Rather, that there are two things you might mean by "move x to a.3". One is to insert at position a.3, shifting elements up as needed. The other is "replace the element currently at a.3 with x". Presumably if one is valuable, both are. I'm just trying to get a sense of the scope of the issue.

Comment by Billy Tetrud [ 21/Mar/16 ]

Why would it? I don't understand the question. Sometimes you need to move things within an array, and I can also see cases where you want to move things between arrays within a document. There's no command I know of that allows mongo to do this without transferring all the data back and forth over the wire, so the real question is: why wouldn't there be a way to do that?

Comment by Andy Schwerin [ 21/Mar/16 ]

Interesting. It would need a little more definition. Why, for example, would a move into a specific array position act like a vector insert and not just overwrite the value currently at the location?

Comment by Billy Tetrud [ 21/Mar/16 ]

Hmm, looks like case 1 can be done with $rename. Case 2 could be done without transferring data by querying for whether various fields $exists, but use a projection that doesn't return that data, then do multiple $rename commands. Complicated, but it works.

It looks like case 3 can't be done with $rename. I propose in that case, that either $rename gets an option somehow that can move items within a list in a way that shifts the appropriate elements, or that a new operator (like $move) be created specifically for that purpose.

Comment by Andy Schwerin [ 21/Mar/16 ]

Can you achieve what you're looking for with the $rename update operator, fresheneesz?

Comment by Billy Tetrud [ 18/Mar/16 ]

What I meant by the stuff about "potentially large amounts of data" is that without a $move operator, you have to pass potentially large amounts of data to set a field, and in the case of multiple move, first save potentially large amounts of data so you can then move it elsewhere.

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