[dna-issues] [JBoss JIRA] Commented: (DNA-546) JCR Workspace and Session Imports Can Fail on JPA Connector

[ https://jira.jboss.org/jira/browse/DNA-546?page=com.atlassian.jira.plugin... ] Brian Carothers commented on DNA-546: ------------------------------------- The root cause of this behavior is the Basic model's composite primary key for node entities (workspace ID, node UUID). This approach is very efficient in general, but causes problems with the portions of the TCK that require replacement of nodes with the same UUIDs (e.g., document imports that contain nodes with a UUID that is already in use with the workspace). In this case, the default implementation in the JCR layer tries to delete the existing node with a given UUID and then add a new node (usually in a different location) with the same UUID. This would require the JPA session to contain two versions of the same entity (one being deleted and another being added). This just doesn't work under the JPA spec. So then the question becomes "how does this get fixed?" One approach would be to modify the JCR import (and workspace copy and clone) code to implement an update of this type instead of a delete/insert strategy. This approach would require a two-pass approach. First, the UUIDs of all of the incoming nodes would have to be collected, then the potential nodes that might be deleted would have to be computed. This set of added nodes would be a proper subset of the deleted nodes, since deleting a node implies deleting all of its ancestors as well. After that, the nodes that would have been deleted and then inserted would have to be moved to their new location and their children removed, but this would have to be ordered carefully since the removed children may themselves be moved as part of the operation. That's not everything that would need to happen to work around this, but it's already a lot. And only one current (or planned) connector has this problem, so it's pretty debatable whether it should have been solved in the JCR layer anyway. Alternatively, we could just add a new model for the JPA connector which was built to support this in the first place. I'm going to try that first. My proposed model is based on the current model (the "Basic" model) and in fact would reuse a fair amount of the common code. The new model would have three main changes from the Basic model: 1. It would have an artificial key to avoid the problem described in this defect. 2. It would store the node and its properties in a single table (collapsing the ChildEntity and PropertiesEntity from the Basic model into a single NodeEntity) 3. It would be based on the MapRepository so that it can reuse most of the working, debugged MapRequestProcessor implementation. I expect to retain the mechanism for managing large properties and tracking references from the BasicModel. I also am reusing the property serialization code since it's already been tested and shaken down. Any feedback on this approach is, as always, welcome. -- 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