Remy Maucherat wrote:
>
> > Hi,
> >
> > A MOVE request is handled by Macro.move which performs a copy followed
> > by a delete.
> > This has the following drawbacks:
> > - The underlying store might provide an API for moving that is much
> > faster. In unix terms:
> > moving an INODE is much faster than copying a complete sub-tree and
> > deleting the source
> > afterwards. I would suggest adding 'moveXxx' methods to the various
> > store interfaces just like
> > 'createXxx', 'retrieveXxx', 'storeXxx', etc. (the default
> > implementation could still be copy followed by
> > delete).
>
> I know, but I believe that's way too complex to implement in many cases.
Why? We could easily have the move interfaces implemented in
StandardStore.java as a copy/delete, as we do currently - then specific
stores (like FileContentStore) that have a way to do things MUCH
faster/more efficiently/more correctly can override that. Or are there
interactions between the different stores (i.e. content vs. metadata)
that would be too hard to control this way?
>
> > - The permissions for deletion are checked after the copy operation.
> > This means that you need to
> > wait for the full copy operation (and it's rollback) before an error
> > response is sent.
>
> True. We could add a check to see if the source can be deleted before doing
> anything else.
That would certainly improve the situation, but isn't a long term
solution (see previous mail) unless you just want to serialise all store
access (perhaps optionally - so stores which require it can ask for
that, or something...) - but that'll really hurt performance in high
load cases.
Michael
