[dna-issues] [JBoss JIRA] Commented: (DNA-508) Workspace move/clone referenceable nodes is failing

Randall Hauch (JIRA) jira-events at lists.jboss.org
Fri Aug 28 11:25:23 EDT 2009


    [ https://jira.jboss.org/jira/browse/DNA-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12483413#action_12483413 ] 

Randall Hauch commented on DNA-508:
-----------------------------------

One of the problems was that the workspace move method implementation (down in GraphSession) was not changing the children (of the new and old parent) to reflect the newly removed/added children.  The correction was simply a call to an existing method (similar to what was being done in copy).

The second problem was the fact that clone was not removing from the session state (again, down in GraphSession) the nodes that were being removed during the clone operation, and therefore the session state had nodes that no longer existed in the persistent store.  Unfortunately, the set of nodes that were indeed removed as part of the clone operation was not available after the fact, so correcting this behavior required adding the Set<Location> of these deleted nodes into the CloneBranchRequest.  This in turn mandated that all writable connector implementations be changed to set this information as part of the processing of these requests.  Once this was done, the GraphSession could be changed to use this information to remove these nodes from its cache.  

Incidentally, I discovered another possible error condition regarding clone.  Consider a session node A, which has the same UUID as node B in another workspace.  If that session attempts to clone node B (from the other workspace) and the clone method's removeExisting parameter is true, then node A needs to be removed in order for the clone to succeed.  So far this is the normal situation.  However, if node A has transient changes, then it cannot be removed from the session.  Therefore, I changed the JcrWorkspace.clone(...) method to check for this case and throw a RepositoryException.  (The spec did not delineate this error condition, so I'm assuming that this is the best type of exception to throw.)  Luckily, the method was already checking that the would-be-deleted nodes were not mandatory, so also checking whether the node has local changes was very easy.

The two TCK unit test suites mentioned above now pass completely.

> Workspace move/clone referenceable nodes is failing
> ---------------------------------------------------
>
>                 Key: DNA-508
>                 URL: https://jira.jboss.org/jira/browse/DNA-508
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> Two TCK unit test suites ("WorkspaceMoveReferenceableTest" and "WorkspaceCloneReferenceableTest") are not working.  These did work before the DNA-466 changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the dna-issues mailing list