You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2006/05/02 16:08:46 UTC
[jira] Created: (JCR-423) Node.restore() fails for existing
non-versioned OPV=Version child nodes
Node.restore() fails for existing non-versioned OPV=Version child nodes
-----------------------------------------------------------------------
Key: JCR-423
URL: http://issues.apache.org/jira/browse/JCR-423
Project: Jackrabbit
Type: Bug
Components: versioning
Versions: 1.0, 0.9
Reporter: Tobias Bocanegra
Assigned to: Tobias Bocanegra
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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-423) Node.restore() fails for existing
non-versioned OPV=Version child nodes
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-423?page=all ]
Tobias Bocanegra resolved JCR-423:
----------------------------------
Fix Version: 1.0.1
Resolution: Fixed
fixed in r398968
> Node.restore() fails for existing non-versioned OPV=Version child nodes
> -----------------------------------------------------------------------
>
> Key: JCR-423
> URL: http://issues.apache.org/jira/browse/JCR-423
> Project: Jackrabbit
> Type: Bug
> Components: versioning
> Versions: 1.0, 0.9
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
> Fix For: 1.0.1
>
> 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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-423) Node.restore() fails for existing
non-versioned OPV=Version child nodes
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-423?page=comments#action_12413410 ]
Jukka Zitting commented on JCR-423:
-----------------------------------
Merged for 1.0.1 in revision 409609.
> Node.restore() fails for existing non-versioned OPV=Version child nodes
> -----------------------------------------------------------------------
>
> Key: JCR-423
> URL: http://issues.apache.org/jira/browse/JCR-423
> Project: Jackrabbit
> Type: Bug
> Components: versioning
> Versions: 1.0, 0.9
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
> Fix For: 1.0.1
>
> 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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (JCR-423) Node.restore() fails for existing
non-versioned OPV=Version child nodes
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-423?page=all ]
Tobias Bocanegra reopened JCR-423:
----------------------------------
the opv=copy issue is resolved, but another appeared:
newly added opv=version child nodes are not removed when restoring an older version of the node, not containing that nodes.
> Node.restore() fails for existing non-versioned OPV=Version child nodes
> -----------------------------------------------------------------------
>
> Key: JCR-423
> URL: http://issues.apache.org/jira/browse/JCR-423
> Project: Jackrabbit
> Type: Bug
> Components: versioning
> Versions: 1.0, 0.9
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
> Fix For: 1.0.1
>
> 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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-423) Node.restore() fails for existing
non-versioned OPV=Version child nodes
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-423?page=all ]
Tobias Bocanegra resolved JCR-423:
----------------------------------
Resolution: Fixed
fixed (again).
Committed revision 405417.
> Node.restore() fails for existing non-versioned OPV=Version child nodes
> -----------------------------------------------------------------------
>
> Key: JCR-423
> URL: http://issues.apache.org/jira/browse/JCR-423
> Project: Jackrabbit
> Type: Bug
> Components: versioning
> Versions: 1.0, 0.9
> Reporter: Tobias Bocanegra
> Assignee: Tobias Bocanegra
> Fix For: 1.0.1
>
> 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?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira