hi jukka would we in this case still have the need for Root#copy? wouldn't it be better then to just drop that and build Workspace#copy in oak-jcr altogether?
kind regards angela On 05/02/14 19:02, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Wed, Feb 5, 2014 at 12:40 PM, Angela Schreiber <[email protected]> >wrote: >> - flag the copy-target like we do it for the move operations >> - perform the low-level copy (as we do it today) >> - create commit hooks that > >Sounds way too complex and error-prone to me. I didn't want to comment >during the call as the brainstorming could have resulted in some new >ideas here, but so far I don't think we have anything that would be as >clean as implementing the copy using a simple content traversal on top >of the access control layer. Even perfomance shouldn't really be an >issue here, as with the MongoMK you in any case need to create new >documents for the new nodes and with the SegmentMK the travesal is >really fast -- and as in both cases the large binary values that would >be most costly things to copy are in any case copied by reference. > >> maybe we also want to discuss on whether or not it would make sense to >> define the copy operation on the oak api to be also a singular >>'workspace' >> operations as it is the case in JCR... this would prevent us from ending >> up having nested and complex combinations of copy, move and other >> modifications in the same commit. > >If we treat copy as suggested above, there should be no need for the >extra complexity, as from the repository perspective the copy would >look like an import. > >BR, > >Jukka Zitting
