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@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
