[ZODB-Dev] Referential integrity

Mike C. Fletcher mcfletch@rogers.com
Fri, 01 Mar 2002 17:47:30 -0500


I actually had to deal with referential integrity problems in an app 
just two weeks ago.  Best approach I found was to wire in a watcher that 
looks for ObjectDeleted events on the collection, and on finding one, 
does the scan explicitly.  Similarly, the property classes for the 
objects refresh conflict sub-tables and check object consistency as soon 
as an attribute is altered.

Of course, that's not a real solution for robust referential integrity. 
  Designing such a system for my apps is _way_ beyond my skill (and, 
really, needs for such small projects)... as far as I can see, you'd 
need a computer engineer with some serious experience who could create a 
"provably correct" mechanism (integrity being an all-or-nothing 
attribute) without making the whole programme just up-and-barf(TM) when 
it finds an integrity problem.

The hardest problem (I think) is in designing generic support code for 
what to do when the integrity is lost (e.g.):

	What do I do when I copy in an object O that has a req. reference to 
object P?
		Insert object P first
		Then insert object O
		except when I didn't want P, I wanted a similar object already in the database
		then do something else


You almost need to handle it with:

	raise ReferentialIntegrityFailure(
		objects = theInvalidObjects,
		rule = theRule,
		exception = exceptionObject,
		resumeContinuation = continuationObject,
		transaction = transactionObject,
		...,
	)

But then you're still back to "okay, I know there's an error, and can 
process it when I get it, but I have to catch it everywhere" semantics. 
  You can invert the structure to a function 
handleReferentialIntegrityFailure( ... ), but again, you're stuck 
calling it everywhere.

All-in-all, I'd agree with Jim, sounds like it's application level for 
the "handling code".  Don't know about the lower-level. A way to specify 
when to do a raise ReferentialIntegrityFailure would be nice, but 
without re-writing pickle so that it does an 
isThisObjectReachableElsewise( object ) check for certain references, I 
don't really see a way to do it easily.  And specifying when to do that 
would likely be as (or more) complex as (than) writing a function 
isObjectInCollectionICareAbout( object ) and adding it to your property 
class's boundary conditions and the collection watchers.

Sigh :) ,
Mike

Jim Fulton wrote:
> Arnaud Bienvenu wrote:
> 
>>On Fri, Mar 01, 2002 at 09:47:37AM -0500, Jim Fulton wrote:
>>
>>>What list? There is no way to explicitly remove
>>>an object from the database.  An object will be removed
>>>from the database when it is no longer referenced.
>>>
>>I understand that, but I want to set up constraints in my model,
>>
> ....
> 
> Your model should be implemented in a layer above ZODB. It might be 
> supported by an application framework that lots of different 
> applications share.  The framework would (at least mostly) ignore
> ZODB.
> 
> ZODB take a sort of "micro-kernal" approach to database features.
> ZODB simply supports persistence. Application features like indexing, 
> security, relational models, high-level constraints, etc, are the
> responsability of higher level layers.
> 
> Jim
> 
> --
> Jim Fulton           mailto:jim@zope.com       Python Powered!        
> CTO                  (888) 344-4332            http://www.python.org  
> Zope Corporation     http://www.zope.com       http://www.zope.org
> 
> _______________________________________________
> For more information about ZODB, see the ZODB Wiki:
> http://www.zope.org/Wikis/ZODB/
> 
> ZODB-Dev mailing list  -  ZODB-Dev@zope.org
> http://lists.zope.org/mailman/listinfo/zodb-dev
> 
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/