> Why are the consistency check method needed on RepositoryImpl?
To build a tool that can call this programmatically. The configuration based variant needs a restart and fiddling with workspace.xml
> Consistency checking a large workspace is a heavy weight operation that may have performance effects.
I improved the check so that it allows you to specify single nodes via uuids.
> Shouldn't such an operation only be allowed to an admin user (-> login required)?
Makes sense. How would I check this inside RepositoryImpl?
> > [...] problems with cache coherence and other such stuff.
> why exactly is that an issue? the consistency check works on the persistence manager level, which does not know about transient changes?
Cached bundles that get deleted by the consistency check on the database level will lead to problems. The cache needs to be invalidated. This is still an open issue...
> > to clean up the versioning "workspace", pass "jcr:system" as workspace name
> I would rather use the uuid of the jcr:system node and the method checkConsistency(String uuids, boolean)
RepositoryImpl just calls the consistency check on the persistence manager. Therefore you can specify the workspace in the checkConsistency() methods that will select the PM of the chosen workspace. It was natural to select the versioning PM with a special name then.
I am open for another solution. My question at this point: The versioning PM stores all versions for all workspaces, right? If the nodes in the versioning space have backreferences to the workspace nodes, they have to be global?
> checkConsistency(String uuids) is a convenience method, right? I'd remove that one.
Yes, the only one really needed is RepositoryImpl.consistencyCheck(String workspace, String uuids, boolean recursive, boolean fix). The other methods in RepositoryImpl and WorkspaceImpl are for convenience (entire workspace check is done via uuids=null).
Shall I go for developer convenience or axiomatic, ie. minimalistic approach here?