jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Kahwe Smith <...@pooteeweet.org>
Subject Re: Support for long multivalued properties
Date Thu, 15 Nov 2012 12:15:02 GMT

On Nov 15, 2012, at 12:59 , Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:

> On Thu, Nov 15, 2012 at 12:00 PM, Jukka Zitting <jukka.zitting@gmail.com> 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.
> personally i am not aware of real life use cases requiring 'large' mv
> properties.
> since the ultimate goal of oak is to provide a JCR implementation and the
> JCR API doesn't provide any methods to manipulate/access single members
> of a mv property i don't think we need to support it under the hood.

i am also not aware of any real world use cases here ..
that being said .. before adding this i would rather want to see support for hash maps.

Lukas Kahwe Smith

View raw message