Community
Participate
Working Groups
Build Identifier: Our Setup: We have a CDO Repository with Referential Integrity enabled. The repository stores various models holding information related to our Software Development Lifecycle as well as models holding information related to reverse engineering activities. Human Users edit the models of our Software Development Lifecycle while batch process changes the models in the area of reverse engineering. For the human changes, we need the referential integrity checks, while the batch processes do huge changes on the reverse engineering models and commit the changes in on single transaction. The batch processes checks the referential integrity by there self using the query API provided by a CDOView public List<CDOObjectReference> queryXRefs(Set<CDOObject> targetObjects, EReference... sourceReferences); A batch processe can produce up to 50'000 detached objects with around 200'000 removed EReferences already checked for referential integrity object by object. If such an amount of changes is commited in one single transaction, the referential integrity blows up the database (Oracle) behind the repo. ENHANCEMENT REQUEST: It would be nice if the CDOTransaction could support a toggle for disable the referential integrity check e.g transaction.options().ensureReferentialIntegrity(false); Reproducible: Always
Röbi, please note that it's not possible to ensure an equal level of referential integrity without requiring all commits to go through the built-in check. In your case a human user could remove objects after your "external" ref check has finished but before the results are committed. Is that really what you want?
(In reply to comment #1) > Röbi, please note that it's not possible to ensure an equal level of > referential integrity without requiring all commits to go through the built-in > check. > > In your case a human user could remove objects after your "external" ref check > has finished but before the results are committed. Is that really what you > want? I totally agree. This is dangerous and should be used carefully cause it can result in inconsistent model states. That's why i explicitly mentioned our case with human users and our batch process. Human users in our scenario are not authorized to change something on the models created by the batch processes. Those are seperated areas in the repository.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
