Effect of KernelRootBuilder update

2012-11-16 Thread Michael Dürig
Hi, I was having a look at KernelRootBuilder.update() which saves pending changes down to a branch in the Microkernel after a certain threshold in the number of changes. I was wondering if this has any effect at all. The branch is never merged back. Or is that branch only used as a

Re: Effect of KernelRootBuilder update

2012-11-16 Thread Jukka Zitting
Hi, On Fri, Nov 16, 2012 at 2:48 PM, Michael Dürig mdue...@apache.org wrote: I was having a look at KernelRootBuilder.update() which saves pending changes down to a branch in the Microkernel after a certain threshold in the number of changes. I was wondering if this has any effect at all. The

Re: Effect of KernelRootBuilder update

2012-11-16 Thread Michael Dürig
On 16.11.12 13:00, Jukka Zitting wrote: Hi, On Fri, Nov 16, 2012 at 2:48 PM, Michael Dürig mdue...@apache.org wrote: I was having a look at KernelRootBuilder.update() which saves pending changes down to a branch in the Microkernel after a certain threshold in the number of changes. I was

MongoMK build updates

2012-11-16 Thread Jukka Zitting
Hi, As you may have noticed from the past few commits, I'm working on better integrating the MongoMK to our normal build. The idea is to always build the MongoMK components so we wouldn't need the extra -Pmongomk profile anymore. To do this I'm instructing the test cases that depend on a MongoDB

Re: MongoMK build updates

2012-11-16 Thread Mete Atamel
Hi Jukka, Thanks for setting this up. One minor issue though. The MongoMK build used to take around 2 minutes (see withoutJukkasChanges.txt) but with your changes from yesterday, it takes around 8.5 minutes (see withJukkasChanges.txt). Tests take much longer. This is probably due to how

Re: Support for long multivalued properties

2012-11-16 Thread Alexander Klimetschek
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

Re: hash maps was Re: Support for long multivalued properties

2012-11-16 Thread Jukka Zitting
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

Re: hash maps was Re: Support for long multivalued properties

2012-11-16 Thread Lukas Kahwe Smith
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

Re: hash maps was Re: Support for long multivalued properties

2012-11-16 Thread Jukka Zitting
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

Re: hash maps was Re: Support for long multivalued properties

2012-11-16 Thread Justin Edelson
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