On 22/08/2015 19:59, Manfred Baedke wrote: > Hi, > > OAK-3169 caused inconsistencies that currently have to be repaired > manually, even after a patch has been applied. Since lots of customers > are suffering from this, Andrew Khoury suggested to implement an > optional auto-repair feature, which logs a warning and removes and > re-adds mixin:versionable when a broken version history is found > (losing the version history, of course). > One question would be where to put the repair code, because it's > unclear to me if there might be multiple locations in the Oak code > where an exception might be thrown due to the inconsistency. > Any thoughts?
I'm not familiar with the issue but as far as I can read this applies to all our persistence. And it's pretty core to be in oak-core. On the other hand if rep:versionablePath is only related to JCR and we can deal with the fix from a JCR point of view, ie without accessing the NodeStore layer, I would say it fits better in oak-jcr. if instead you're thinking of a tool to be run one-off for fixing the situation I would suggest either a groovy script for the oak console or, yet, another parameter in oak-run. When/how do you detect a broken node? Davide
