You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Alessandro Bologna <al...@gmail.com> on 2008/11/20 17:29:45 UTC
System View XML mapping and multivalued properties
Hi all,
I never gave it too much thought, but I recently encountered an issue
that seems to be a limit case, but nevertheless worth reporting.
If I export a multi valued property in System View, I will obtain an
sv:property element, and as children, a sequence of sv:value elements:
...
<sv:property sv:name="my:list" sv:type="String">
<sv:value>one</sv:value>
<sv:value>two</sv:value>
</sv:property>
...
Now, if my:list happens to have only one element, my export will look
like the following:
<sv:property sv:name="my:list" sv:type="String">
<sv:value>one</sv:value>
</sv:property>
which happens to be exactly the same XML mapping of a "regular",
single valued property (and that's the issue)
The specs (I have jcr 283 handy, so I am quoting form there ) say at
4.4.1:
"A multi-value property is converted to an <sv:property> element
containing multiple <sv:value> elements. The order of the <sv:value>
elements reflects the order of the value array returned by
Property.getValues" (4.4.1)
So this as by specs. But, when I import it (and the assumption is that
I want to roundtrip my data, which should be supported in the System
View), the logic is implemented (I believe in in
o.a.j.core.xml.PropInfo) as follow: if there's a node type definition
that tells me that this node is multi valued or if I don't have
exaclty one value, set it as such, otherwise set it as single valued.
This works fine if there's a node type definition that constrains this
property, but if there's none (unstructured nodes all around) then my
roundtrip will create a node that is not exaclty like the original
one, and if the application is using getValues() it will probably
throw an exception:
"Accessing a multi-valued property with Property.getValue, or a
single-value property with Property.getValues will throw a
ValueFormatException" (3.7.1)
Which in turns forces the application code to recover in the catch
using getValue(). I think is dangerous and quite inefficient to do so,
especially in situations where multi valued properties have often a
single value (say for instance my:authors).
Maybe I am missing something, but if that's the case that I am not,
maybe it would be worth adding some implementation specific
workaround, such as adding an optional sv:multivalued="true" attribute
that then can be used transparently during import. It should not break
anything I believe (unless there's some strict validation of the SV
schema in place). Or was this intentional?
Thoughts?
Alessandro
Re: System View XML mapping and multivalued properties
Posted by Stefan Guggisberg <st...@day.com>.
hi alessandro
On Thu, Nov 20, 2008 at 6:51 PM, Alessandro Bologna
<al...@gmail.com> wrote:
> Thanks Jukka,
> I guess i have been a bit lazy not looking at the jira first ;)
>
> Alex, yes, JSR-283 does not seem to address the issue at all (just like
> 170). Maybe, if there's somebody who happens to read this thread and is in
> the committe, that person could propose to address it (hint hint)...
i just checked. there's already a JSR 283 issue (BTW reported by me
in april this year, my memory seems to suffer with age...;) it's been fixed
in the current (non-public) draft. however, there's a minor problem, the
newly introducedl attribute is not in the 'sv' namespace, as you correctly
proposed. i'll create a new issue to address this.
cheers
stefan
>
> In the end, System View is the only way to guarantee data
> migration/interoperability between different JCR implementations and it's
> not a minor issue when the the contents are ambiguously serialized (and we
> all dislike silos...)
>
> In the meanwhile, with our JCR (JR of course) I think that the solution
> presented by Stefan (using a rep: attribute on the sv:property, if I
> understand him correclty) may be the way to go (just in case somebody is
> validating the SV schema strictly, to add an attribute in a different
> namespace may be less intrusive). It seems to be a minor change in the code.
> Then once JR becomes 2.0 compliant, we could use sv:multivalued="true" or
> something like that.
>
> Thanks.
> Alessandro
>
>
>
>
>
>
> On Thu, Nov 20, 2008 at 12:36 PM, Alexander Klimetschek <ak...@day.com>wrote:
>
>> I looked at the JCR 2.0 spec public review and it does not fix the
>> issue. Do we have a chance to include such a sv:multivalued="true"
>> marker for the 2.0 final?
>>
>> Regards,
>> Alex
>>
>> On Thu, Nov 20, 2008 at 6:09 PM, Jukka Zitting <ju...@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna
>> > <al...@gmail.com> wrote:
>> >> Maybe I am missing something, but if that's the case that I am not,
>> maybe it
>> >> would be worth adding some implementation specific workaround, such as
>> >> adding an optional sv:multivalued="true" attribute that then can be used
>> >> transparently during import. It should not break anything I believe
>> (unless
>> >> there's some strict validation of the SV schema in place).
>> >
>> > You're right, the spec is incomplete in that case and the only thing
>> > we could do for now is to add some implementation-specific multivalue
>> > marker. See also https://issues.apache.org/jira/browse/JCR-1464.
>> >
>> > BR,
>> >
>> > Jukka Zitting
>> >
>>
>>
>>
>> --
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
>>
>
Re: System View XML mapping and multivalued properties
Posted by Alessandro Bologna <al...@gmail.com>.
Thanks Jukka,
I guess i have been a bit lazy not looking at the jira first ;)
Alex, yes, JSR-283 does not seem to address the issue at all (just like
170). Maybe, if there's somebody who happens to read this thread and is in
the committe, that person could propose to address it (hint hint)...
In the end, System View is the only way to guarantee data
migration/interoperability between different JCR implementations and it's
not a minor issue when the the contents are ambiguously serialized (and we
all dislike silos...)
In the meanwhile, with our JCR (JR of course) I think that the solution
presented by Stefan (using a rep: attribute on the sv:property, if I
understand him correclty) may be the way to go (just in case somebody is
validating the SV schema strictly, to add an attribute in a different
namespace may be less intrusive). It seems to be a minor change in the code.
Then once JR becomes 2.0 compliant, we could use sv:multivalued="true" or
something like that.
Thanks.
Alessandro
On Thu, Nov 20, 2008 at 12:36 PM, Alexander Klimetschek <ak...@day.com>wrote:
> I looked at the JCR 2.0 spec public review and it does not fix the
> issue. Do we have a chance to include such a sv:multivalued="true"
> marker for the 2.0 final?
>
> Regards,
> Alex
>
> On Thu, Nov 20, 2008 at 6:09 PM, Jukka Zitting <ju...@gmail.com>
> wrote:
> > Hi,
> >
> > On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna
> > <al...@gmail.com> wrote:
> >> Maybe I am missing something, but if that's the case that I am not,
> maybe it
> >> would be worth adding some implementation specific workaround, such as
> >> adding an optional sv:multivalued="true" attribute that then can be used
> >> transparently during import. It should not break anything I believe
> (unless
> >> there's some strict validation of the SV schema in place).
> >
> > You're right, the spec is incomplete in that case and the only thing
> > we could do for now is to add some implementation-specific multivalue
> > marker. See also https://issues.apache.org/jira/browse/JCR-1464.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
Re: System View XML mapping and multivalued properties
Posted by Alexander Klimetschek <ak...@day.com>.
I looked at the JCR 2.0 spec public review and it does not fix the
issue. Do we have a chance to include such a sv:multivalued="true"
marker for the 2.0 final?
Regards,
Alex
On Thu, Nov 20, 2008 at 6:09 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna
> <al...@gmail.com> wrote:
>> Maybe I am missing something, but if that's the case that I am not, maybe it
>> would be worth adding some implementation specific workaround, such as
>> adding an optional sv:multivalued="true" attribute that then can be used
>> transparently during import. It should not break anything I believe (unless
>> there's some strict validation of the SV schema in place).
>
> You're right, the spec is incomplete in that case and the only thing
> we could do for now is to add some implementation-specific multivalue
> marker. See also https://issues.apache.org/jira/browse/JCR-1464.
>
> BR,
>
> Jukka Zitting
>
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: System View XML mapping and multivalued properties
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Nov 20, 2008 at 5:29 PM, Alessandro Bologna
<al...@gmail.com> wrote:
> Maybe I am missing something, but if that's the case that I am not, maybe it
> would be worth adding some implementation specific workaround, such as
> adding an optional sv:multivalued="true" attribute that then can be used
> transparently during import. It should not break anything I believe (unless
> there's some strict validation of the SV schema in place).
You're right, the spec is incomplete in that case and the only thing
we could do for now is to add some implementation-specific multivalue
marker. See also https://issues.apache.org/jira/browse/JCR-1464.
BR,
Jukka Zitting