Transient workspace#clone alternative

[Matej Knopp-2]

Hi,

Since workspace#clone works directly on persistent storage it's usage
turned out to be very limiting for us. All calls to the #clone methods
have to be "self contained" in respect that no nodes can be referenced
outside srcAbsPath, otherwise ConstraintViolationException occurs. So
if i want to clone two nodes with circular dependencies I'm out of
luck, unless i clone parent of those nodes, right?

So far the only workaround i could think about is to implement own
alternative if workspace#clone, but there are several drawbacks.
 - I'll lose the original UUID
 - I'll lose history information
 - I'll duplicate the binary data

Am I missing something or is this really the only way to go?

Kind regards,
Matej

[Tobias Bocanegra]

hi,
On 5/13/08, Matej Knopp <matej.knopp@...> wrote:
>  Since workspace#clone works directly on persistent storage it's usage
>  turned out to be very limiting for us. All calls to the #clone methods
>  have to be "self contained" in respect that no nodes can be referenced
>  outside srcAbsPath, otherwise ConstraintViolationException occurs. So
>  if i want to clone two nodes with circular dependencies I'm out of
>  luck, unless i clone parent of those nodes, right?
that is true and maybe is a flaw in the design of this method.

>  So far the only workaround i could think about is to implement own
>  alternative if workspace#clone, but there are several drawbacks.
>   - I'll lose the original UUID
>   - I'll lose history information
>   - I'll duplicate the binary data
>
>  Am I missing something or is this really the only way to go?
currently there is only 1 way of controlling the UUIDs of newly
created methods, that is by importing sysview. so what you can do is
create a XML snippet or generate sax events that creates your node
with the respective UUID.
for the sake of cloning, you can also export the node in one workspace
and then import in on the other.

--
toby

[Matej Knopp-2]

On Tue, May 13, 2008 at 8:08 AM, Tobias Bocanegra
<tobias.bocanegra@...> wrote:

> hi,
>
> On 5/13/08, Matej Knopp <matej.knopp@...> wrote:
>  >  Since workspace#clone works directly on persistent storage it's usage
>  >  turned out to be very limiting for us. All calls to the #clone methods
>  >  have to be "self contained" in respect that no nodes can be referenced
>  >  outside srcAbsPath, otherwise ConstraintViolationException occurs. So
>  >  if i want to clone two nodes with circular dependencies I'm out of
>  >  luck, unless i clone parent of those nodes, right?
>  that is true and maybe is a flaw in the design of this method.

Any chance of this being addressed in JCR 2.0? I think this really is
a flaw and it doesn't have any easy workarounds.

>
>
>  >  So far the only workaround i could think about is to implement own
>  >  alternative if workspace#clone, but there are several drawbacks.
>  >   - I'll lose the original UUID
>  >   - I'll lose history information
>  >   - I'll duplicate the binary data
>  >
>  >  Am I missing something or is this really the only way to go?
>  currently there is only 1 way of controlling the UUIDs of newly
>  created methods, that is by importing sysview. so what you can do is
>  create a XML snippet or generate sax events that creates your node
>  with the respective UUID.
>  for the sake of cloning, you can also export the node in one workspace
>  and then import in on the other.

If i could simply export node in one workspace and import in another i
would do that with Workspace#clone. Problem is, that I can't, because
the node has dependencies. Creating simple XML snippet for the node to
preserve UUID could work (thanks for the tip), unfortunately that
won't help me with duplicating the binary content.

-Matej
>
>  --
>  toby
>



--
Resizable and reorderable grid components.
http://www.inmethod.com

[Matej Knopp-2]

On Tue, May 13, 2008 at 9:36 AM, Matej Knopp <matej.knopp@...> wrote:

> On Tue, May 13, 2008 at 8:08 AM, Tobias Bocanegra
>  <tobias.bocanegra@...> wrote:
>  > hi,
>  >
>  > On 5/13/08, Matej Knopp <matej.knopp@...> wrote:
>  >  >  Since workspace#clone works directly on persistent storage it's usage
>  >  >  turned out to be very limiting for us. All calls to the #clone methods
>  >  >  have to be "self contained" in respect that no nodes can be referenced
>  >  >  outside srcAbsPath, otherwise ConstraintViolationException occurs. So
>  >  >  if i want to clone two nodes with circular dependencies I'm out of
>  >  >  luck, unless i clone parent of those nodes, right?
>  >  that is true and maybe is a flaw in the design of this method.
>  Any chance of this being addressed in JCR 2.0? I think this really is
>  a flaw and it doesn't have any easy workarounds.
>
>
>  >
>  >
>  >  >  So far the only workaround i could think about is to implement own
>  >  >  alternative if workspace#clone, but there are several drawbacks.
>  >  >   - I'll lose the original UUID
>  >  >   - I'll lose history information
>  >  >   - I'll duplicate the binary data
>  >  >
>  >  >  Am I missing something or is this really the only way to go?
>  >  currently there is only 1 way of controlling the UUIDs of newly
>  >  created methods, that is by importing sysview. so what you can do is
>  >  create a XML snippet or generate sax events that creates your node
>  >  with the respective UUID.
>  >  for the sake of cloning, you can also export the node in one workspace
>  >  and then import in on the other.
>  If i could simply export node in one workspace and import in another i
>  would do that with Workspace#clone. Problem is, that I can't, because
>  the node has dependencies. Creating simple XML snippet for the node to
>  preserve UUID could work (thanks for the tip), unfortunately that
>  won't help me with duplicating the binary content.

On second thought, I can copy everything except the jcr:content nodes
and then just clone the jcr:content nodes (since they don't contain
any references), which should not result in binary data duplication
(when using DataStore).

-Matej

>
>  -Matej
>  >
>  >  --
>  >  toby
>  >
>
>
>
>  --
>  Resizable and reorderable grid components.
>  http://www.inmethod.com
>

--
Resizable and reorderable grid components.
http://www.inmethod.com

[Tobias Bocanegra]

On 5/13/08, Matej Knopp <matej.knopp@...> wrote:

> On Tue, May 13, 2008 at 8:08 AM, Tobias Bocanegra
>  <tobias.bocanegra@...> wrote:
>  > hi,
>  >
>  > On 5/13/08, Matej Knopp <matej.knopp@...> wrote:
>  >  >  Since workspace#clone works directly on persistent storage it's usage
>  >  >  turned out to be very limiting for us. All calls to the #clone methods
>  >  >  have to be "self contained" in respect that no nodes can be referenced
>  >  >  outside srcAbsPath, otherwise ConstraintViolationException occurs. So
>  >  >  if i want to clone two nodes with circular dependencies I'm out of
>  >  >  luck, unless i clone parent of those nodes, right?
>  >  that is true and maybe is a flaw in the design of this method.
>
> Any chance of this being addressed in JCR 2.0? I think this really is
>  a flaw and it doesn't have any easy workarounds.

not sure. i'm going to address this on the list. thanks for reporting.
--
toby

>
>
>  >
>  >
>  >  >  So far the only workaround i could think about is to implement own
>  >  >  alternative if workspace#clone, but there are several drawbacks.
>  >  >   - I'll lose the original UUID
>  >  >   - I'll lose history information
>  >  >   - I'll duplicate the binary data
>  >  >
>  >  >  Am I missing something or is this really the only way to go?
>  >  currently there is only 1 way of controlling the UUIDs of newly
>  >  created methods, that is by importing sysview. so what you can do is
>  >  create a XML snippet or generate sax events that creates your node
>  >  with the respective UUID.
>  >  for the sake of cloning, you can also export the node in one workspace
>  >  and then import in on the other.
>
> If i could simply export node in one workspace and import in another i
>  would do that with Workspace#clone. Problem is, that I can't, because
>  the node has dependencies. Creating simple XML snippet for the node to
>  preserve UUID could work (thanks for the tip), unfortunately that
>  won't help me with duplicating the binary content.
>
>  -Matej
>  >
>  >  --
>  >  toby
>  >
>
>
>
>
>  --
>  Resizable and reorderable grid components.
>  http://www.inmethod.com
>