jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Support for long multivalued properties
Date Thu, 15 Nov 2012 11:48:43 GMT

Support for large mv props was a non goal initially: 

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.


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