On Nov 15, 2012, at 12:59 , Stefan Guggisberg <stefan.guggisb...@gmail.com> wrote:
> On Thu, Nov 15, 2012 at 12:00 PM, Jukka Zitting <jukka.zitt...@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. i am also not aware of any real world use cases here .. that being said .. before adding this i would rather want to see support for hash maps. regards, Lukas Kahwe Smith m...@pooteeweet.org
