jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Support for long multivalued properties
Date Thu, 15 Nov 2012 14:53:31 GMT

To my knowledge groups members listed in a mv property is to my knowledge the only use case
of large mv properties. So I am inclined to assume that this is an implementation detail of
the group membership maintenance rather than of the repository as a whole.

In addition, Stefan makes a valid point: The JCR API only allows access to the mv properties
by array. So as soon as you access the properties, JCR users have to have the array in any

So, I doubt we need large mv property support. But I am sure we need "large group membership"
support, which is not the same.


Am 15.11.2012 um 12:48 schrieb Michael Dürig:

> Support for large mv props was a non goal initially: 
> http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrabbit%203
> However, I'm fine with revisiting that since I think there might be 
> valid use cases. See for example Angela's mail in this thread.
> At the very least I think we should not build something which prevents 
> us from adding support for large mv. props later on.
> Michael
> On 15.11.12 11:00, Jukka Zitting wrote:
>> Hi,
>> This came up earlier in the Berlin Oakathon and we're now facing it
>> also with the property index. Basically, do we want to add explicit
>> support for long (>> 1k values) multivalued properties?
>> Currently such properties are possible in theory since there is no
>> hard limit to the size of the value array, but in practice accessing
>> such properties requires reading the whole array to memory and even a
>> simple update (like appending a single value) requires the whole array
>> to be rewritten.
>> There are two ways of supporting use cases that require such long
>> multivalued properties: a) we can support it directly in the
>> repository, or b) we require the client to use more complex data
>> structures like in the BTreeManager in Jackrabbit trunk or the BTree
>> implementation in the wrapper-based index implementation Thomas wrote
>> for Oak.
>> Supporting such use cases directly in the repository would be nice as
>> that would notably simplify affected clients. However, doing so would
>> require us to adapt some of our APIs. For example we'd need a way to
>> iterate over the list of values of a single property and to add, set
>> and remove individual values at specific locations. The
>> PropertyBuilder interface already has some of this, but neither the
>> Oak API nor the MicroKernel currently support such operations.
>> WDYT, should we implement something along these lines or leave it up
>> to clients? I'm cautiously positive in that we should do this since
>> we'd in any case need similar code for the property index, but would
>> love to hear other opinions.
>> BR,
>> Jukka Zitting

View raw message