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: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Support for long multivalued properties
From: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <0E30E9D2-C2AF-46E2-8799-0954A23ADACE@adobe.com>
Date: Thu, 15 Nov 2012 16:30:28 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <673C0AAF-D902-4565-A2D0-1BC98D4269F5@pooteeweet.org>
References: <CCCAA5FB.3739A%mueller@adobe.com>
 <8035DC13-DA1D-4A9F-961B-C3BD7A0B3614@pooteeweet.org>
 <0E30E9D2-C2AF-46E2-8799-0954A23ADACE@adobe.com>
To: oak-dev@jackrabbit.apache.org


On Nov 15, 2012, at 15:50 , Felix Meschberger <fmeschbe@adobe.com> =
wrote:

> Hi,
>=20
> Am 15.11.2012 um 14:06 schrieb Lukas Kahwe Smith:
>=20
>>=20
>> On Nov 15, 2012, at 14:02 , Thomas Mueller <mueller@adobe.com> wrote:
>>=20
>>> Hi,
>>>=20
>>>> before adding this i would rather want to see support for hash =
maps.
>>>=20
>>> Sounds interesting.. could you give more details please?
>>=20
>>=20
>> well right now you can only store "ordered lists".
>> especially in PHP its common to use associative arrays
>>=20
>> $var =3D array(
>> 'foo' =3D> 'bar',
>> 'ding' =3D> 'dong',
>> )
>=20
> Hm, this looks more like node "var" with properties "foo" set to "bar" =
and "ding" set to "dong" to me.


not really .. the same could be said about any multi valued property =
otherwise :)
i guess hash maps are not a common pattern in Java, but they are quite =
common in scripting languages.

also for scripting languages it generally makes little sense to "blow =
up" a simple structure into lots of subnodes for performance reasons.

at any rate in our data mapper we currently support this splitting hash =
maps into 2 multi valued properties and we are making quite a lot of use =
of this. f.e. we use this to store a list of named options.

TYPO3, who created a JCR inspired content repository, also named the =
lack of hash maps as a reason why they in the ended diverged.

it was my understanding that Oak tries to become more viable for remote =
access from other languages, in that case it would make sense to look =
into this. at any rate .. i didnt mean to high jack this thread. so if =
there is interest to discuss this further it would be best to open a new =
thread.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org