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
Hi,

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
case.

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

Regards
Felix

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
>> 


Mime
View raw message