Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360793

Summary:	Possiblity to disable Referential Integrity Check on Transaction Level
Product:	[Modeling] EMF	Reporter:	Robert Blust <robert.blust>
Component:	cdo.core	Assignee:	Project Inbox <emf.cdo-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	stepper
Version:	4.13
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Robert Blust

2011-10-13 06:49:04 EDT

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

Comment 1 Eike Stepper

2011-10-13 07:05:29 EDT

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?

Comment 2 Robert Blust

2011-10-13 08:20:41 EDT

(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.

Comment 3 Eike Stepper

2012-08-14 22:57:45 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 4 Eike Stepper

2013-06-27 04:08:50 EDT

Moving all outstanding enhancements to 4.3

Comment 5 Eike Stepper

2014-08-19 09:28:17 EDT

Moving all open enhancement requests to 4.4

Comment 6 Eike Stepper

2014-08-19 09:37:33 EDT

Moving all open enhancement requests to 4.4

Comment 7 Eike Stepper

2015-07-14 02:21:32 EDT

Moving all open bugzillas to 4.5.

Comment 8 Eike Stepper

2016-07-31 01:04:18 EDT

Moving all unaddressed bugzillas to 4.6.

Comment 9 Eike Stepper

2017-12-28 01:10:07 EST

Moving all open bugs to 4.7

Comment 10 Eike Stepper

2019-11-08 02:06:12 EST

Moving all unresolved issues to version 4.8-

Comment 11 Eike Stepper

2019-12-13 12:45:01 EST

Moving all unresolved issues to version 4.9

Comment 12 Eike Stepper

2020-12-11 10:36:57 EST

Moving to 4.13.