jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: oak-api and move operations
Date Fri, 30 Mar 2012 14:20:20 GMT
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.

cheers
stefan

> BR,
>
> Jukka Zitting

Mime
View raw message