Upon further consideration, here’s an alternative proposal. To recap the problem: Say version 1.0.x has an issue that leads to repo inconsistencies or even (repairable) data loss The issue is fixed in 1.0.y, but users running an inbetween version might have experienced that data loss (maybe without noticing).
If we only put the repair code in oak-run then users first need to notice the problem, before even running the repair. Otoh I still think that we should stay clear of complicating the core code. So, alternative proposal: put such repair code in a new module (bundle), say, oak-selfheal. That way we could at least keep core clean from that. In this case oak-jcr could automatically detect the problem and invoke the repair code. However, I am not sure if we have many of these situations where a) the problem can be detected and b) repaired automatically to warrant such a new module. Thoughts? Michael On 24/08/15 10:55, "Marcel Reutegger" <[email protected]> wrote: >Hi, > >On 24/08/15 10: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. > >agreed. in addition, the tool could be split into two phases. >in the first phase the tool just checks the repository and finds >all the dangling references. this phase could also be run on >a copy of the data. in a second phase the tool fixes nodes >based on the output from the first phase. this reduces impact >on the production instance. > >Regards > Marcel >
