Re: Using same index definition for both async and sync indexing

Opened OAK-4641 for this enhancement Chetan Mehrotra On Wed, Aug 3, 2016 at 8:00 PM, Chetan Mehrotra wrote: > On Wed, Aug 3, 2016 at 7:52 PM, Alex Parvulescu > wrote: >> sounds interesting, this looks like a good option. >> > > Now comes

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

Opened OAK-4640 to track this Chetan Mehrotra On Wed, Aug 3, 2016 at 9:36 PM, Michael Dürig wrote: > > > On 3.8.16 5:58 , Chetan Mehrotra wrote: >> >> On Wed, Aug 3, 2016 at 8:57 PM, Michael Dürig wrote: >>> >>> I would suggest to add an new, internal

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

On 3.8.16 5:58 , Chetan Mehrotra wrote: On Wed, Aug 3, 2016 at 8:57 PM, Michael Dürig wrote: I would suggest to add an new, internal mechanism to CommitInfo for your purpose. So introduce a new CommitAttributes instance which would be returned by CommitInfo ... ?

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

On Wed, Aug 3, 2016 at 8:57 PM, Michael Dürig wrote: > I would suggest to add an new, internal mechanism to CommitInfo for your > purpose. So introduce a new CommitAttributes instance which would be returned by CommitInfo ... ? Chetan Mehrotra

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

So maybe we need some additional means to survey this context then. If you look at https://issues.apache.org/jira/browse/OAK-1438 where the commit info map was introduced and at the usages of the same, it is evident that this map belongs to the client (i.e. caller). Modifying it midway

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

That would depend on the CommitHook impl which client code would not be aware of. And commit hook would also know only as commit traversal is done. So it needs to be some mutable state Chetan Mehrotra On Wed, Aug 3, 2016 at 8:27 PM, Michael Dürig wrote: > > Couldn't we keep

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

Couldn't we keep the map immutable and instead add some "WhateverCollector" instances as values? E.g. add a AffectedNodeTypeCollector right from the beginning? Michael On 3.8.16 4:06 , Chetan Mehrotra wrote: So would it be ok to make the map within CommitInfo mutable ? Chetan Mehrotra

Re: Using same index definition for both async and sync indexing

On Wed, Aug 3, 2016 at 7:52 PM, Alex Parvulescu wrote: > sounds interesting, this looks like a good option. > Now comes the hard part ... what should be the name of this new interface ;) ContextualIndexEditorProvider? Chetan Mehrotra

Re: Using same index definition for both async and sync indexing

> So we can have a marker value to indicate empty agreed, we could have null, '' and/or 'default' basically map to the same idea: sync index. > And there we introduce something like IndexingContext which folds in > IndexUpdateCallback, indexing mode, index path, CommitInfo etc sounds

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

So would it be ok to make the map within CommitInfo mutable ? Chetan Mehrotra On Wed, Aug 3, 2016 at 7:29 PM, Michael Dürig wrote: > >> >> #A -Probably we can introduce a new type CommitAttributes which can be >> attached to CommitInfo and which can be modified by the

Re: Way to capture metadata related to commit as part of CommitInfo from within CommitHook

#A -Probably we can introduce a new type CommitAttributes which can be attached to CommitInfo and which can be modified by the CommitHooks. The CommitAttributes can then later be accessed by Observer This is already present via the CommitInfo.info map. It is even used in a similar way. See

Re: Using same index definition for both async and sync indexing

On Wed, Aug 3, 2016 at 2:23 PM, Alex Parvulescu wrote: > extend the current index definition > for the 'async' property and allow multiple values. That should work and looks like natural extension of the flag. Just that having empty value in array does not look good

Re: Using same index definition for both async and sync indexing

Hi, I don't have a clear proposal for the entire problem, but let me add a few thoughts to the info you provided. It looks like there are 2 problems we need to fix: first one is indexer being picked up by two threads (sync and async), second one is indexer needs to know if it is running in a sync

[Oak origin/1.2] Apache Jackrabbit Oak matrix - Build # 1077 - Failure

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #1077) Status: Failure Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1077/ to view the results. Changes: [amitj] OAK-4454: Create consistent API in ExternalSort to write