On 16.11.2012, at 16:08, Justin Edelson jus...@justinedelson.com wrote:
Who says he can't? I think the point Alex and Jukka were tying to make is
that JCR already supports a data structure which can be converted into a
hash.
Exactly. JCR doesn't need a new property type map, as properties on
On 15.11.2012, at 12:59, Stefan Guggisberg stefan.guggisb...@gmail.com wrote:
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
Hi,
On Fri, Nov 16, 2012 at 12:39 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
which is the reason why it would be great to add hash maps to JCR. storing
hash maps
as nodes with a single property is simple not efficient with an interpreted
language
where there is native support for
On Nov 16, 2012, at 13:18 , Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Fri, Nov 16, 2012 at 12:39 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
which is the reason why it would be great to add hash maps to JCR. storing
hash maps
as nodes with a single property is simple not
Hi,
On Fri, Nov 16, 2012 at 2:24 PM, Lukas Kahwe Smith m...@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
On Fri, Nov 16, 2012 at 8:42 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:
On Fri, Nov 16, 2012 at 2:14 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
...i really feel like this is a clash of worlds here ..
...and modularity is usually the answer in such cases ;-)
I'm only
hi jukka
if we decide that having long mv properties is a valid use-case
we should have support for that in the repository.
back in jackrabbit-core i remember just one case where this
limit actually was a problem: the group members stored in a
mv property... and michael at that time added to
Support for large mv props was a non goal initially:
http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrabbit%203
However, I'm fine with revisiting that since I think there might be
valid use cases. See for example Angela's mail in this thread.
At the very least I
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
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
Hi,
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
Hi,
before adding this i would rather want to see support for hash maps.
Sounds interesting.. could you give more details please?
Regards,
Thomas
Hi,
Am 15.11.2012 um 14:06 schrieb Lukas Kahwe Smith:
On Nov 15, 2012, at 14:02 , Thomas Mueller muel...@adobe.com wrote:
Hi,
before adding this i would rather want to see support for hash maps.
Sounds interesting.. could you give more details please?
well right now you can only
13 matches
Mail list logo
