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 12:25:42 GMT
On Fri, Mar 30, 2012 at 2:18 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Fri, Mar 30, 2012 at 2:05 PM, Michael Dürig <mduerig@apache.org> wrote:
>> I don't know about the details of the algorithm Git uses. But *if* that
>> algorithm *does* reconstruct move and copy operations from looking at the
>> raw trees, I'm pretty sure they annotated the trees in some ways to track
>> that information.
>
> Ultimately it's just a comparison of matching content, see the -M and
> -C options in git-diff(1). Git uses content hashes to optimize such
> comparisons.
>
>> However, that doesn't solve the issue at hand. If we go down that route, why
>> should we bother at all and reconstruct the operations from the state only
>> to construct a JSOP statement to be given to Microkernel.commit()? We should
>> rather do away with this entirely and pass the new tree directly to the
>> Microkernel.
>
> 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?

cheers
stefan

>
>>> More generally, what's the use case where this functionality is
>>> needed? I'd be happy to even drop support for NODE_MOVED observation
>>> events unless we have real clients that actually require that
>>> information (as opposed to just create/update/delete events).
>>
>> I'd be fine with that. However, if clustering relies on journal scrapping,
>> this is not an option.
>
> Good point. Intuitively I'd be fine with placing such a restriction on
> the underlying clustering implementation, though it would be really
> nice if we had some performance/scalability figures to back that
> assumption.
>
> BR,
>
> Jukka Zitting

Mime
View raw message