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: Conflict handling in Oak
Date Tue, 18 Dec 2012 15:51:12 GMT


On 18.12.12 15:30, Stefan Guggisberg wrote:
> On Tue, Dec 18, 2012 at 4:08 PM, Michael Dürig <mduerig@apache.org> wrote:
>>
>>
>> On 18.12.12 14:43, Thomas Mueller wrote:
>>>
>>> Hi,
>>>
>>>>>> 2) Allow inconsistent journals.
>>>>>
>>>>>
>>>>> I guess we don't want that. But the question is how close the journal
>>>>> has
>>>>> to match the original commit, specially "move" and "copy" operations.
If
>>>>> they need to be preserved (do they?), then it's complicated.
>>>>
>>>>
>>>> There is no use for a journal which is not accurate. After all, if we
>>>> consider implementing rebase (OAK-464) on top of the journal, it has to
>>>> be accurate.
>>>
>>>
>>> Yes, I think we should have a consistent journal, if we have a journal.
>>>
>>> But the question is how close the journal has to match the original
>>> commit, specially "move" and "copy" operations.
>>>
>>> So, do "move" and "copy" operations need to be preserved, or can they be
>>> converted to "add node" / "remove node"?
>>
>>
>> Now we are getting somewhere: This is exactly the original topic of OAK-464.
>> If the Microkernel converts moves to add/remove, implementing rebase on top
>> of that results in moves of big sub trees to become *very* expensive.
>
> IIRC we didn't consider efficient move operations a design goal.
> i guess we can live with non-optimized move operations.

Right. However, degrading moves to remove/add node operations limits the 
size of sub trees which can be moved: if the moved sub tree (serialised 
to json add node operations) do not fit into heap, moves wont work at all.

Michael

>
> cheers
> stefan
>
>>
>> Michael
>>
>>>
>>>
>>> Regards,
>>> Thomas
>>>
>>>
>>

Mime
View raw message