Hi, We quite often see that some merge conflicts occur while creating/pruning hierarchy for content under Property Index hidden tree. We have an issue to reduce the effects vide OAK-2673 [0] -- while enabling it is prone to OAK-2929 [1], but even if it worked correctly, it'd just resolve add-add and delete-delete conflicts... leaving out delete-changed type conflicts.
I was wondering if we can do asynchronous pruning instead. While I understand why pruning is useful, but having a few extra paths temporarily probably shouldn't be that bad. I'm not sure of how AsyncIndexer, LuceneIndexer type stuff works -- but, I'm assuming they'd be keeping some sort of bookmark to note which revision has already been processed. I guess we can do something similar here too. BTW, do these indexers process independent of each other -- would it make sense to chain such jobs so that each of these can work with just one calculation of diff? There's another idea: does it make sense for a document to assert that it's semantically an 'intermediate' document -- created just to form a hierarchy, hence conflicts related to such documents can be handled accordingly. For OAK-2673, we had a heuristic for this -- the conflicts were resolved for a document which lied under hidden tree and had no visible properties. May be, we can even have a mixin for this -- as the hierarchy intent could be very useful even for applications (I've seen lot of automated tests that need to pre-create hierarchy just to avoid such a conflict... ). Thoughts? Thanks, Vikas [0]: https://issues.apache.org/jira/browse/OAK-2673 [1]: https://issues.apache.org/jira/browse/OAK-2929
