On 15.11.12 15:30, Lukas Kahwe Smith wrote:
well right now you can only store "ordered lists".
especially in PHP its common to use associative arrays
$var = array(
'foo' => 'bar',
'ding' => 'dong',
)
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.
We could also put this the other way around: a multi valued property is
a special case of a map with integers as keys and some special rules
regarding insertion and deletion. From this POV it seems feasible to
make multi valued properties a special case of the more general case of
maps. But see below...
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 ..
Adding "deep" support for maps would requite major changes to the stack.
The underlying data model, which was decided upon pretty early on, is
based on the assumption that values are either Json atoms or Json
arrays. See http://wiki.apache.org/jackrabbit/Jsop.
Michael
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
m...@pooteeweet.org
