oh, ok. i see. you're talking of restore of an existing node. that would be a bug then :-)
On 5/2/06, David Kennedy <[EMAIL PROTECTED]> wrote:
Hi Toby, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 > > > > > -- > -----------------------------------------< [EMAIL PROTECTED] >--- > 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 >---
-- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
