I can agree that such feature is rather workaround, but this solution is quick and really works. As I wrote it will be not recommended to use it, it is only for experience JCR users which will be aware of any possible drawbacks.
From other point of view using any relational database you can also temporarly disable constraint checking to speedup some bulk operations, then enable it again. And in some cases it is very helpfull.
>references are a core feature of jsr-170 which imo must not be compromised through public api methods.
I dot't need it exposed through public API. What I need is to have some methods which I can call on any component (could be RepositoryImpl, or WorkspaceImpl).
For now we have implemented this by extending SISM class and overriding some methods. But then our code is depenedent on Jackrabbit, and could stop work with newest versions.
>Consider a big subtree of items (1 mio items, eg.), which you might want to delete. Just switching off integrity checks does not help here
I think it helps, because you can remove tree in steps without worrying about references.
>we should address the real issue instead.
I really agree with you, but changing this could mean redesigning of jackrabbit core and it does not look that it could happen in the near future.
Stefan, Felix, could you recommend any other feasible solution for my use cases?