Hi, Could someone please update OAK-3169 with a link to the new issue, or the resolution?
Regards, Thomas 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 > >
