RepositoryService moveNode not using destinationRepository
Brought to you by:
agrebnev,
perez_martin
Menu
▾
▴
#16 RepositoryService moveNode not using destinationRepository
The RepositoryService methods for moving and copying Nodes, Documents, Directories, and Resources all take a destinationRepository parameter which is unused by the JCRRepositoryService implementation. As a result, the value of the String can be any not null value, and the method only works within the single repository that the ticket is registered to.
Is there a current alternative approach that allows a server side movement of nodes without causing potentially unnecessary network traffic?
Logged In: YES
user_id=579235
Originator: NO
Hi Dave,
That is true. I do not think this should be a bug fix request though but a feature request.
Cross-repository operations was a feature that was available in early beta jLibrary versions. However, it turned out to be over-complicated for initial releases and so it was disabled. Think about it, is not just a matter of moving/copying the doc. but also handling all the internal links: document categories, document permissions, document relations, and so on.
Definitely a cool feature to have, but not sure if worth the pain. At the end as you note you can always download the document from one repo and upload it to another repo.
I will change this issue from bug to feature request. Of course, I encourage you to submit a patch or join us to help with this feature, and even more :-)
Logged In: YES
user_id=1834315
Originator: YES
Thanks for the quick reply. No problem with it being a feature request. I have a download/upload version that works fine, so will use that for the moment.
If I find the time, I would love to help, but as always, time is in very short supply ;-)
Logged In: YES
user_id=1834315
Originator: YES
Prior to implementing this enhancement, could you please update the javadoc to highlight that the parameter is not used as yet. This may have saved me some time, and may help others who could fall into the same 'trap'
Logged In: YES
user_id=579235
Originator: NO
Sure Dave,
I have just updated it.
Regards,
Martin