Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNbW-yNdkFsuzWe6UG9vvPJLMCah8SafHVZS2eM0zz_80Q@mail.gmail.com>
References: 
 <CAOFYJNbW-yNdkFsuzWe6UG9vvPJLMCah8SafHVZS2eM0zz_80Q@mail.gmail.com>
Date: Thu, 15 Nov 2012 12:59:07 +0100
Message-ID: 
 <CAFYk8Nkuc-2-m98QXddTuAthLBXMjAuw-9O+pk2EKh7Fp2-fTg@mail.gmail.com>
Subject: Re: Support for long multivalued properties
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 15, 2012 at 12:00 PM, Jukka Zitting <jukka.zitting@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.

cheers
stefan

>
> BR,
>
> Jukka Zitting