You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Lukas Eder (JIRA)" <ji...@apache.org> on 2013/04/02 17:23:17 UTC

[jira] [Commented] (JCR-325) docview roundtripping does not work with multivalue non-string properties

    [ https://issues.apache.org/jira/browse/JCR-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619922#comment-13619922 ] 

Lukas Eder commented on JCR-325:
--------------------------------

I just came across this issue "by accident", as I was missing this feature myself. I personally feel that this is an important missing feature in Jackrabbit, as the document view export occupies much less space than the system view export. Without exporting multi-valued properties, however, it isn't really useful, except maybe for debugging.

How about this rule-set:

1. Multi-valued properties are serialised as originally requested, with a whitespace character (ASCII 0x20) as a separator as specified by w3c's <xsd:list/> type.
2. Whitespace characters contained in multi-valued properties are disambiguated according to the most appropriate scheme in JCR, e.g. by putting _x0020_ (or any more reliable scheme)
3. Nodes containing multi-value properties are "annotated" using an additional attribute specified by a dedicated dv namespace (similar to sv="http://www.jcp.org/jcr/sv/1.0" namespace). dv stands for document view.

Example:

<banana jcr:primaryType="nt:unstructured" 
    multi="A B C_x0020_D" 
    multi2="1 2 3"
    nonMulti="X Y Z"
    dv:multiValue="multi multi2"
/>

In this example, "multi" and "multi2" are multi-valued properties:

- multi = ["A", "B", "C D"]
- multi2 = [1, 2, 3]

Whereas "nonMulti" is a single-valued property:

- nonMulti = "X Y Z"

"dv:multiValue" itself is a multi-valued pseudo-property, which isn't contained in the repository, but is used for export / import only.

Note that adding such an additional namespace might allow exporting more than just the multiValue property in the document view. For example, "protected", "mandatory", "auto-created" flags could be exported as well, or the property type "dv:type", which is redundant with "dv:multiValue", of course.
                
> docview roundtripping does not work with multivalue non-string properties
> -------------------------------------------------------------------------
>
>                 Key: JCR-325
>                 URL: https://issues.apache.org/jira/browse/JCR-325
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: xml
>    Affects Versions: 0.9, 1.0
>         Environment: jackrabbit r379292
>            Reporter: Tobias Bocanegra
>            Assignee: Jukka Zitting
>         Attachments: namespace-context.patch, xml-refactoring.patch
>
>
> 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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira