jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: oak-api and move operations
Date Fri, 30 Mar 2012 15:43:42 GMT


On 30.3.12 15:20, Stefan Guggisberg wrote:
> On Fri, Mar 30, 2012 at 3:45 PM, Jukka Zitting<jukka.zitting@gmail.com>  wrote:
>> Hi,
>>
>> On Fri, Mar 30, 2012 at 2:25 PM, Stefan Guggisberg
>> <stefan.guggisberg@gmail.com>  wrote:
>>> On Fri, Mar 30, 2012 at 2:18 PM, Jukka Zitting<jukka.zitting@gmail.com>
 wrote:
>>>> Exactly. IMHO we should adjust the MK interface to support this. The
>>>> solution should also address handling of large imports.
>>>
>>> sorry, i can't follow you here. could you please elaborate?
>>
>> The main trouble here is that oak-core currently needs to keep the
>> full transient space in memory (or in some other custom non-MK
>> storage) and then serialize it all to a single JSOP string during
>> save().
>>
>> It would be much more convenient if the changes could be incrementally
>> sent to the MicroKernel and tracked as a standard content tree just
>> like any other content. This way we wouldn't need to come up with a
>> separate storage mechanism in oak-core or use temporary subtrees in
>> the main repository to work around this limitation.
>>
>> One way of dealing with this on the MK level would be to introduce the
>> concept of "private branches" that are only visible to a single client
>> until explicitly merged back to the main repository. A quick draft of
>> what this could look like:
>>
>>     String addLotsOfData(MicroKernel mk) {
>>         String baseRevision = mk.getHeadRevision();
>>         String branchRevision = mk.branch(baseRevision);
>>         for (int i = 0; i<  1000000; i++) {
>>             branchRevision = mk.commit(
>>                 "/", "+\"node" + i + "\":{}", branchRevision, null);
>>         }
>>         return mk.merge(branchRevision, baseRevision);
>>     }
>>
>
> good point. the versioning model of the mk has been strictly linear so far
> but i guess your proposal makes sense. we'll have to take into account
> potential implications (gc, getJournal etc) but currently i don't see any
> real problems with supporting 'private' branches.

Just as an aside, this is essentially the same I proposed as early as on 
our first meeting on June 23th last year. I'd wasn't considered a good 
point at all back then...

Michael

>
> cheers
> stefan
>
>> BR,
>>
>> Jukka Zitting

Mime
View raw message