jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukas Kahwe Smith <...@pooteeweet.org>
Subject Re: hash maps was Re: Support for long multivalued properties
Date Fri, 16 Nov 2012 13:14:14 GMT

On Nov 16, 2012, at 13:51 , Jukka Zitting <jukka.zitting@gmail.com> wrote:

> Hi,
> On Fri, Nov 16, 2012 at 2:24 PM, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:
>> I fail to see how it makes sense to use nodes for this. Not only for the above stated
>> reasons but also in terms of querying.
> Oak supports pluggable indexing, so it's straightforward to index
> content in child nodes as part of the parent node. That should make it
> efficient to query such data structures.

but it is a complication that then needs to be dealt with. so while this may be a solution
to the problem, it does require explicit action making it less ideal.

>> I feel the arguments brought forth are very Java centric, which is fine since this
is a
>> Java project. But if the target audience is to also include interpreted languages,
>> this Java centric POV is going in the opposite direction.
> The only Java-angle I see here is the remote vs. local use case where
> our current remoting mechanisms require the content of child nodes to
> be fetched over a separate remote request from that of the parent
> node. That's certainly an area that could/should be improved
> regardless of the language platform being used.

you ignore the fact that with hash map support such properties would then naturally map to
the given native data types rather than node instances which offer features not relevant to
the use case at all when using something like PHPCR. then again PHPCR might not be a target
user while users using the JSON API might be served by your solution (which depends on Oak
never supporting properties and node with overlapping names).

> In fact this is one of the key reasons why also in pure Java
> environments the current Jackrabbit deployment models are somewhat
> limited in terms of how many tiers you can use, and solving the issue
> with Oak would be really useful.
> Looking at this in another way, the way the MicroKernel represents
> nodes is simply as JSON objects, so a structure like { "position": {
> "x": 123, "y", 456 } } is stored simply as a node with a "position"
> child node containing the two properties "x" and "y". I don't see how
> a "map property" could or should work any differently.

yes but even then internally there is obviously some overhead to present such a structure
with nodes rather than a multi valued property supporting hash maps.

i really feel like this is a clash of worlds here .. because none of the arguments I have
read so far make the least bit of sense to me, coming from an interpreted languages world.
i guess its the same way for you guys reading my arguments.

anyway i guess we dont need to come to an agreement on this list as i dont think it would
make sense to add support for hash maps just in Oak but not in JCR, so I instead opened a
ticket on JSR-333 http://java.net/jira/browse/JSR_333-62

Lukas Kahwe Smith

View raw message