[
http://issues.apache.org/jira/browse/JCR-325?page=comments#action_12369622 ]
Jukka Zitting commented on JCR-325:
-----------------------------------
Stefan:
> the multi-value attribute is one of the differentiators being use to identify
> applicable property definitions.
> nt:unstructured for example defines 2 residual properties that only differ in
> the multi-value attribute.
> your approach would not be able to unambiguously determine the 'correct'
> definition because the
> 'multi-valued' information is lost in document view .
You're right, but that's something I'd expect. If the property name matches
both a single- and a multi-valued property and the property value doesn't hint
the correct interpretation (like when a reference property contains a space),
then it should be reasonable to default for the single-valued definition. We
could even have some heuristics about the property value containing _xFFFF_
escapes when the correct property definition cannot otherwise be determined.
This approach would cover the original case reported by Tobias as well as a
majority of normal use cases.
The solution with a marker character only works when doing import/export
between Jackrabbit repositories, but fails when importing content from other
sources like original XML documents, exports from other JCR implementations, or
results of XSL transformations written based on the JCR spec. This solution
also explicitly breaks the rules in section 6.4.2.5 of the JSR 170 spec.
I'd use the following heuristic for interpreting the import of a document view
property named N with value V:
1) If N matches just a single property definition, interpret V according to
that definition.
2) Otherwise N matches a single-valued definition S and a multi-valued
definition M:
2.1) If V contains whitespace and S is not a string property definition,
interpret V according to M
2.2) If V contains _xFFFF_ escapes and M is not a string property
definition, interpret V according to S
2.2) If V contains _xFFFF_ escapes, interpret V according to M
2.3) Otherwise interpret V according to S
This heuristic doesn't match all cases, but should work pretty much as expected
for a majority of use cases.
> docview roundtripping does not work with multivalue non-string properties
> -------------------------------------------------------------------------
>
> Key: JCR-325
> URL: http://issues.apache.org/jira/browse/JCR-325
> Project: Jackrabbit
> Type: Bug
> Components: core
> Versions: 0.9
> Environment: jackrabbit r379292
> Reporter: Tobias Bocanegra
> Assignee: Stefan Guggisberg
>
> when exporting a multivalue property with docview, the property values are
> serialized to a space delimited list in the xml attributes:
> for example:
> <?xml version="1.0" encoding="UTF-8"?>
> .
> .
> <testNode
> jcr:primaryType="refTest"
> refs="b5c12524-5446-4c1a-b024-77f623680271
> 7b4d4e6f-9515-47d8-a77c-b4beeaf469bc"
> />
> the refTest nodetype was:
> [refTest]
> - refs (reference) multiple
> importing this docview fails with: javax.jcr.ValueFormatException: not a
> valid UUID format
> this is due to the fact, that the space delimited list is not exploded
> anymore. actually this code is commented:
> org.apache.jackrabbit.core.xml.DocViewImportHandler, lines 191 - 200:
> /*
> // @todo should attribute value be interpreted as LIST type
> (i.e. multi-valued property)?
> String[] strings = Text.explode(attrValue, ' ', true);
> propValues = new Value[strings.length];
> for (int j = 0; j < strings.length; j++) {
> // decode encoded blanks in value
> strings[j] = Text.replace(strings[j], "_x0020_", " ");
> propValues[j] = InternalValue.create(strings[j]);
> }
> */
> i haven't tested, but i assume this also fails for all other non-string
> property types.
--
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
