Hi, As Stefan and I noted in our comments to JCR-954, the real issues is not integrity checking but transient item spaces held in-memory during the transaction. This problem cannot be solved by just adding some raw mode of whatever sort and restriction. Rather than resorting to such a hacky workaround for a concrete use case, we should try to solve the general problems underlying this specific use case.
Consider for example a subtree of - say - 10 Millions items you wish to delete. You will run into the very same memory issues as noted in JCR-954. But the "raw" mode will not help you out here... On the other hand, proper integrity is at the heart of every professional data repository and IMHO is one of the strongholds of the JCR. Another reason to not add such a "raw" mode. Regards Felix On 5/31/07, Jukka Zitting <[EMAIL PROTECTED]> wrote:
Hi, Every now and then I see people running into issues with the current limitations in modifying node types in Jackrabbit. The recent JCR-954 issue also highlighted a similar problem with referential integrity checks. For various reasons the strict integrity checks in Jackrabbit end up hurting valid use cases. The proper solution to the problem would be to actually implement the missing node type modification support and to optimize the use cases in JCR-954, but it seems to me that we are at least a year if not more away from such solutions. Thus I would like to float the idea of a "raw mode" in Jackrabbit. The "raw mode" would be a session-level attribute, enabled during login, that would disable all node type and reference checks for that session. The mode would only be available to administrator users, perhaps even only when no other sessions are accessing the repository. BR, Jukka Zitting
