jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kennedy <da...@us.ibm.com>
Subject Re: Restore of node with child node having onParentVersion=VERSION fails
Date Tue, 02 May 2006 13:52:35 GMT
Hi Toby,

tobias.strasser@gmail.com wrote on 05/02/2006 02:14:48 AM:

> hi david,
> you need to checkin that childnode aswell, before you are able to
> restore the node. otherwise, there is no version you can restore from.
> since the rootversion is only a sentinel of the version history, it
> cannot be restored from.

But the child node definition has onParentVersion=VERSION.  According to 
the spec....

"On restore of VN, if the workspace currently has an already existing node
corresponding to C?s version history and the removeExisting flag of the
restore is set to true, then that instance of C becomes the child of the
restored N." 

Since the workspace has the existing child, that child should become the 
child of the restored parent (i.e. nothing should really be restored from 
version history).  IMO, the restore should work the opposite of the 
checkin.  If I checkin a parent and it has a child with 
onParentVersion=VERSION, and that checkin merely causes a reference to the 
versionHistory of the child, then on restore, there is nothing to restore 
*unless* there is no child in the workspace at which point it would pull 
the "latest" from versionHistory.

David

> 
> regards, toby
> 
> On 5/1/06, David Kennedy <davek@us.ibm.com> wrote:
> > I have a node whose definition has properties and child nodes.  The
> > definitions of the nodetypes for the node and the child include
> > mix:versionable.  The properties definitions have onParentVersion=COPY 
and
> > the child nodes have onParentVersion=VERSION.  When I create a node 
with
> > child nodes and checkin and then restore the node, I get a
> > "....VersionException: Restore of root node not allowed"  This is
> > occurring on the restore of the child node.
> >
> > According to the spec:
> >
> > Child Node
> > On checkin of N, the node VN will get a subnode of type 
nt:versionedChild
> > with the same name as C. The single property of this node,
> > jcr:childVersionHistory is a REFERENCE to the version history of C 
(not to
> > C or any actual version of C). This also requires that C itself be
> > versionable (otherwise it would not have a version history).
> > .
> > .
> > .
> > On restore of VN, if the workspace currently has an already existing 
node
> > corresponding to C?s version history and the removeExisting flag of 
the
> > restore is set to true, then that instance of C becomes the child of 
the
> > restored N. If the workspace currently has an already existing node
> > corresponding to C?s version history and the removeExisting flag of 
the
> > restore is set to false then an ItemExistsException is thrown.
> >
> >
> > I'm restoring the node using
> >
> >     node.restore(version, true);
> >
> > Is this expected behavior?
> >
> > David
> >
> 
> 
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message