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