[elephant-devel] Referential Integrity

[Robert L. Read]

If one could operate under the assumption that most of the database fits
into memory, I would say the act of dealing with references that would
be left dangling is definitely better handled at the "business object"
layer.  This would mean that in the "delete" method for each class, it
would know who might refer to it and take appropriate action, such as
querying the managers of the referrers to find referrers and then
deleting them.  Writing such code is similar to establishing a cascading
delete constraint (or a "cascading finalizer" or "cascading :after
method", which would be more general.)  If we had a constraint system,
it would probably be easier, but less general, than a coded approach.

However, if you don't assume this, then I think that you are correct in
that it essentially becomes equivalent to the garbage collection
problem.

Personally, I rather the like the idea of being able to do:

(apply #'function to-my-whole-gigantic-database),

where #'function could be a garbage collector, or a "delete-if-null"
function.

Make it fast might be another matter.

I personally don't want to compete against other constraint-based
systems, so if I were going to implement a constraint like "this slot
must point to a valid persistent object", then I would try to write as a
simple lisp function, and then try to figure out how to apply it
efficiently in two relevant cases:  Write before a transaction is
committed, so that we can guarantee universal constraint obedience, and
two the entire database (for the same reason.)

It is at least in theory possible for a transaction to know what it
might have modified, and therefore to implement the first efficiently.



On Wed, 2008-06-11 at 12:02 -0400, Ian Eslick wrote:
> While Elephant currently has a reasonable method for lazy handling of  
> broken dependencies (pointers from an object slot to an object that no  
> longer exists), it doesn't provide any reasonable method for computing  
> the set of broken dependancies when an object is dropped.
> 
> I'm finding for my current application that this would be very useful  
> (if I delete a person's account, I need to delete all objects created  
> by that refer to that user or that the user refers to that aren't  
> linked to anything else.  Ideally this would be handled by a garbage  
> collector, but think about this in the context of indexing.
> 
> For example, imagine a User instance references a Profile instance and  
> a set of SurveyAnswer instance (with indexed slots user and name)  
> point back to the User instance.
> 
> When I delete the User all SurveyAnswer and the Profile instance  
> should also be deleted, otherwise when I go through all SurveyAnswers  
> of a given name, I get an answer instance that reference a user that  
> doesn't exist.  Those dangling entries need to be removed from the  
> indices.
> 
> I'd like to extend the current drop API along the lines of:
> 
> - related-instances - a collection of all objects that would be  
> rendered invalid on a drop
> - drop-instance - add a :drop-related t keyword to walk the graph and  
> delete all related insts
> 
> 
> There are several approaches to gathering the information necessary to  
> compute this:
> 
> - Manual code to perform cleanup (Today)
> 
> - Explicit declarations of object dependencies
>    For example a constraint class argument in defpclass?  Or a more  
> direct method of telling the database about dependencies between class/ 
> slot values and instances of classes.  This would be automatically  
> maintained for associations?)
> 
> - Implicit declarations via type information in slots
> 
> - Fully automated
> 
> This last one is probably too much overhead.  Dynamic types mean we'd  
> have to check types at runtime which involves far more overhead to the  
> slot access functions than I'd like.  We're already a bit heavy on  
> checks in slot access dispatch.
> 
> 
> Does anyone have experience implementing something like this?  Any  
> suggestions or recommendations?
> 
> Thank you,
> Ian
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel