After experimenting a bit with modeshape we found that it is very easy to make the modeshape database unstable to the point where you cannot startup modeshape at all. I was wondering if anyone else experienced these problems, and how you protect yourself against these corrupt database content problems. Can you recover if the database gets 'broken'?
In a nutshell, these are a few of situations that caused problems:
- Create a new namespace with an existing URI. Old namespace gets replaced but with a different prefix. After restarting, modeshape will not startup.
- Deleting a namespace does not check if it is still in use. After restart, nodetypes get loaded but namespace is not found and modeshape will not startup.
Many of these operations are expected not to occur, and it's fairly easy for your client applications to intelligently do (or not do) these operations. For example, you shouldn't create a new namespace with the URI of an existing namespace; instead, you should first change the URI of the existing namespace to something reasonable.
However, we should still make sure that ModeShape fails to start after such changes are made. Can you log an issue so that we can make this more robust and stable?
- Deleting a nodetype does not check if the type is still in use. This will survive a restart, but obviously data is not correct anymore (still pointing to a non existing nodetype)
- Deleting a protected property is allowed. You can simply delete jcr:primaryType, which of course should not be allowed
These should not be happening. Can you please log separate issues for each of these?
Can you also attach test cases? We do have logic that attempts to handle most (if not all) of these cases, so we'd like to find out why that logic isn't working in your cases.
As requested, the 4 issues + test cases. Hope these help