On 30.3.12 15:20, Stefan Guggisberg wrote:
On Fri, Mar 30, 2012 at 3:45 PM, Jukka Zitting<[email protected]> wrote:
Hi,
On Fri, Mar 30, 2012 at 2:25 PM, Stefan Guggisberg
<[email protected]> wrote:
On Fri, Mar 30, 2012 at 2:18 PM, Jukka Zitting<[email protected]> 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
