jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Parvulescu <alex.parvule...@gmail.com>
Subject Re: One hook to rule them all
Date Fri, 22 Feb 2013 09:28:10 GMT
more info on what I had in mind, I was thinking that the majority of the
CommitHooks work on the same principle: the commit hooks creates a
NodeStateDiff implementation, then it applies the diff, next the new state
is returned.

My initial try was to shortcut this mechanism but allowing a CommitHook to
return directly a NodeStateDiff impl (and not apply it directly), next if
you can come up with a delegating diff that can simply traverse the
hierarchy once and apply the diff, the problem is solved.
I almost had this going until I ran into some CommitHooks that deviate from
this standard behavior (like the ValidatingHook for ex which needs a root
validator)


alex


On Fri, Feb 22, 2013 at 10:20 AM, Alex Parvulescu <alex.parvulescu@gmail.com
> wrote:

> good point.
>
> I managed to do that for the indexing part (IndexHookManager &
> IndexHookManagerDiff). the diff is processed only once and then the changes
> are delegated to each available impl.
> I was thinking about applying the same principle to the entire commit hook
> stack but I wasn't able to pull it off.
>
> alex
>
>
> On Fri, Feb 22, 2013 at 8:50 AM, Tommaso Teofili <teofili@adobe.com>wrote:
>
>> Hi Jukka,
>>
>> On 22/feb/2013, at 08:44, Jukka Zitting wrote:
>>
>> > Hi,
>> >
>> > We currently have half a dozen different commit hooks looking at each
>> > commit. This means that each content diff is traversed at least half a
>> > dozen times before the commit can be completed. As Thomas noted, this
>> > causes a lot of extra reads especially with larger commits.
>> >
>> > I'd like to try unifying our various hooks into extensions of one
>> > super hook that traverses the content diff only once, calling out to
>> > individual validators and sub-hooks where necessary, a bit like how
>> > the ValidatingHook already operates.
>>
>> +1, that sounds like a simple and valuable performance improvement.
>>
>> Regards,
>> Tommaso
>>
>> >
>> > BR,
>> >
>> > Jukka Zitting
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message