jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Support for long multivalued properties
Date Thu, 15 Nov 2012 11:59:07 GMT
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.

cheers
stefan

>
> BR,
>
> Jukka Zitting

Mime
View raw message