jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Support for long multivalued properties
Date Thu, 15 Nov 2012 11:40:12 GMT
hi jukka

if we decide that having long mv properties is a valid use-case
we should have support for that in the repository.

back in jackrabbit-core i remember just one case where this
limit actually was a problem: the group members stored in a
mv property... and michael at that time added to workaround
to store group-members in a tree structure, which as a
couple of drawbacks in particular with oak among others that
there is no way to define a dedicated index for that structure.
so, i was  thinking of slightly adjusting it for oak... but
obviously having  support for huge mv-properties (even if the
group members would be split to several properties) would definitely
be helpful here... but i admit that this doesn't make it a
valid, high prio use-case... it would just be cool.

kind regards

On 11/15/12 12:00 PM, 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