For one-time repair actions a script is available.
When/how do you detect a broken node?
With the current Oak we see an InvalidStateException when checkin tries
to get the base revision. Of course there might be multiple code paths
suffering from the inconsistency, so picking one of them doesn't make
things better overall.
On 24.08.15 04:02, Michael Marth wrote:
IMO we should collect such repair actions in oak-run. This should be a one-off
action that should not complicate code in oak-core I think.
my2c
Michael
On 24/08/15 08:46, "Davide Giannella" <[email protected]> wrote:
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
