jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: oak-api and move operations
Date Fri, 30 Mar 2012 12:18:15 GMT
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.

>> 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