[dna-issues] [JBoss JIRA] Updated: (DNA-365) Workspace.importXml and getContentHandler Are Not Implemented

[ https://jira.jboss.org/jira/browse/DNA-365?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-365: -------------------------------- Attachment: DNA-365.patch Attached a patch with an approach that almost works. Salient features are: - Added a method to JcrSession to create a Graph.Batch from the current session graph - Added a method to SessionCache to specify a Graph.Batch to be used with a SessionCache.NodeEditor. The returned NodeEditor will queue all operations into the given Graph.Batch, allowing the original caller to execute that batch outside of the default SessionCache context. - Moved most validation logic from setProperty and addMixin in AbstractJcrNode and JcrMultiValueProperty into corresponding methods in SessionCache.NodeEditor, allowing these operations to be (relatively) simply performed on a user-specified Graph.Batch. - Modified JcrContentHandler to directly invoke these methods on SessionCache.NodeEditor - Modified JcrContentHandler to specify a Graph.Batch directly when saving in workspace mode. Combined with the previous change, this allows direct writes to the persistence layer when in workspace mode. - Added implementation of getContentHandler and importXml in JcrWorkspace. However, the patch causes some regressions. The DNA layer does not distinguish between single-valued and multi-valued properties at this time. The JCR spec mandates that the two be treated differently and makes them generally incompatible. It is possible for a node type to allow a property with a given name to be either single-valued or multi-valued (e.g., the residual definition on nt:unstructured). When the SessionCache loads a property from the persistence layer, it tried to use the node type to determine whether the property is single-valued or multi-valued in the JCR sense. If the node type does not allow SessionCache to distinguish the cardinality of the property by name, SessionCache heuristically determines the cardinality based on the current number of values for the property (1 value => JcrSingleValuedProperty, else => JcrMultiValuedProperty). This leads to the following pathological case: 1. Get a reference to a node with a primary type that does not always disambiguate between property cardinality based on name alone (e.g., nt:unstructured) 2. Call setProperties(String, Value[]) on the node with a Value array of length 1 and a non-null value. DNA correctly infers that you are setting a multi-valued property based on the usage of the multi-valued setter. 3. Save the node, persisting the property (and its single value) to the repository. This also flushes the node and its properties from SessionCache, forcing a reload from persistence on the next access. 4. Call node.setProperty(String, String). This should throw a ValueFormatException as mandated by the spec when a called attempts to set a single value on multi-valued property. However, recall that SessionCache flushed the reference on save and had to reload the node and infer the cardinality of its properties. Based on the single-value set on the property, DNA was forced to assume that the property was single-valued and this call will succeed. To address this issue and complete the fix, two issues need to be addressed. First, a mechanism for deterministically separating single-valued properties from multi-valued properties must be created. This may be as simple as appending '*' to the names of multi-valued properties. Next, the cardinality check in SessionCache.NodeEditor.setProperty(Name, Value[], int, boolean) needs to be uncommented, to resume proper cardinality checks. Apologies in advance if the patch is a little off. I had to hand-edit out some of the Session.move 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