You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Markus Joschko <ma...@gmail.com> on 2011/05/13 13:14:28 UTC
MoveOperation always deletes nodes in destination
Hi,
I want to move a node to a new destination where I can have same-name siblings.
I can't use the current MoveOperation as it always deletes the destination node.
if (session.itemExists(destPath)) {
session.getItem(destPath).remove();
}
Is it worthwile to create a patch which checks whether same name
siblings are allowed
and in that case not delete the destination node or should I rather
create my own move operation?
Regards,
Markus
Re: MoveOperation always deletes nodes in destination
Posted by Markus Joschko <ma...@gmail.com>.
On Sat, May 14, 2011 at 9:51 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> On Sat, May 14, 2011 at 11:05 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Hi Markus,
>>
>> On Fri, May 13, 2011 at 4:14 AM, Markus Joschko
>> <ma...@gmail.com> wrote:
>>> I want to move a node to a new destination where I can have same-name siblings.
>>> I can't use the current MoveOperation as it always deletes the destination node.
>>>
>>> if (session.itemExists(destPath)) {
>>> session.getItem(destPath).remove();
>>> }
>>>
>>> Is it worthwile to create a patch which checks whether same name
>>> siblings are allowed
>>> and in that case not delete the destination node or should I rather
>>> create my own move operation?...
>>
>> Same-name siblings are a bad idea in general [1], mostly because their
>> paths are unstable.
>>
>> So IMHO we should leave it as is in Sling and have people create their
>> own move operations if they really want to use same-name siblings.
>
> As I commented on SLING-2078, regardless of goodness or badness of the
> idea of SNS, the patch attached to SLING-2078 can't be applied because
> it isn't backwards compatible. If this behavior is desired, it must be
> explicitly requested using a request parameter (or a configuration
> setting, but I think a request parameter would make more sense).
The parameter is already on the operation :replace. But it is not
respected in a few cases.
However as I stated in the ticket I am a bit shy of modifying that
code as I don't know why it is written the way it is.
>
> Justin
>
>>
>> -Bertrand
>>
>> [1] http://wiki.apache.org/jackrabbit/DavidsModel rule 4
>>
>
Re: MoveOperation always deletes nodes in destination
Posted by Justin Edelson <ju...@justinedelson.com>.
On Sat, May 14, 2011 at 11:05 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Markus,
>
> On Fri, May 13, 2011 at 4:14 AM, Markus Joschko
> <ma...@gmail.com> wrote:
>> I want to move a node to a new destination where I can have same-name siblings.
>> I can't use the current MoveOperation as it always deletes the destination node.
>>
>> if (session.itemExists(destPath)) {
>> session.getItem(destPath).remove();
>> }
>>
>> Is it worthwile to create a patch which checks whether same name
>> siblings are allowed
>> and in that case not delete the destination node or should I rather
>> create my own move operation?...
>
> Same-name siblings are a bad idea in general [1], mostly because their
> paths are unstable.
>
> So IMHO we should leave it as is in Sling and have people create their
> own move operations if they really want to use same-name siblings.
As I commented on SLING-2078, regardless of goodness or badness of the
idea of SNS, the patch attached to SLING-2078 can't be applied because
it isn't backwards compatible. If this behavior is desired, it must be
explicitly requested using a request parameter (or a configuration
setting, but I think a request parameter would make more sense).
Justin
>
> -Bertrand
>
> [1] http://wiki.apache.org/jackrabbit/DavidsModel rule 4
>
Re: MoveOperation always deletes nodes in destination
Posted by Markus Joschko <ma...@gmail.com>.
Hi Bertrand,
> Same-name siblings are a bad idea in general [1], mostly because their
> paths are unstable.
In our application we allow people to reorder the information within
the tree. And they do frequently. So our paths are unstable in
general.
We break with Davids model here and fallback to uuid lookup behaviour.
So paths in our case are more for information then for identification.
> So IMHO we should leave it as is in Sling and have people create their
> own move operations if they really want to use same-name siblings.
I am fine with implementing my own move operation.
Anyway would it be worthwile to extend the move operation? Is it so
uncommon, that people want to move
a resource as child to another resource where one with the same name exists?
Theoretically that is always possible and if I don't want to implement
my error handling on the clientside, I always need to create a custom
move operation to deal with that situation.
If sns shouldn't be used it would be quite handy to specify that the
name generator should be used to generate a new name for the resource
automatically.
Regards,
Markus
Re: MoveOperation always deletes nodes in destination
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Markus,
On Fri, May 13, 2011 at 4:14 AM, Markus Joschko
<ma...@gmail.com> wrote:
> I want to move a node to a new destination where I can have same-name siblings.
> I can't use the current MoveOperation as it always deletes the destination node.
>
> if (session.itemExists(destPath)) {
> session.getItem(destPath).remove();
> }
>
> Is it worthwile to create a patch which checks whether same name
> siblings are allowed
> and in that case not delete the destination node or should I rather
> create my own move operation?...
Same-name siblings are a bad idea in general [1], mostly because their
paths are unstable.
So IMHO we should leave it as is in Sling and have people create their
own move operations if they really want to use same-name siblings.
-Bertrand
[1] http://wiki.apache.org/jackrabbit/DavidsModel rule 4