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 Tue, 03 Apr 2012 10:11:13 GMT

On 3.4.12 11:02, Thomas Mueller wrote:
> Hi,
>> String branchRevision = mk.branch(baseRevision);
>> mk.merge(branchRevision, baseRevision);
> This looks nice, but I'm not sure whether it would work. If merging is the
> responsibility of all MicroKernel implementations, then possibly quite a
> lot of business logic would have to be implemented within each MicroKernel
> implementations (separately).

I think there is some misunderstanding here. There is not more merging 
to be done by the Microkernel as it already does. Currently transient 
changes are kept in memory and passed to the Microkernel in a single 
commit call passing along a possible prohibitively large json diff. With 
the "private branch" approach, the transient changes are simple written 
ahead into a private branch and only on merge are these applied to the 
main branch. Think of it like a write ahead of the json diff to the 
Microkernel (although the implementation might differ).


For example indexing: if two sessions add
> new nodes to branches, and then merge the changes, then the index could
> get corrupt if the added nodes contain the same index values. For
> versioning, similar problems might arise (depending on how versioning is
> implemented). Also, some MicroKernel implementations (for example a
> MongoDB MicroKernel implementation) might not be able to support branching
> and merging.
> I'm against implementing this feature now without careful investigation of
> all possible problems and consequences.
> Relational databases as an example don't support merging, even if they
> support MVCC. For PostgreSQL, if you try to update the same row from
> within two connections and transactions, then the second connection is
> blocked until the first connection commits or rolls back the changes.
> Other databases work in the same way. If merging changes would be simple,
> then I'm sure relational databases would support it.
> Regards,
> Thomas

View raw message