Support for large mv props was a non goal initially: http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrabbit%203
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.
Michael 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
