[storm] How does storm handle dependencies for DELETEs?

[Jason Baker]

I've been working on the following class for some of our integration
tests (these are the relevant parts):

class RowTracker(object):
    def __init__(self, store):
        self.store = store
        self.tracked_objs = []

    def track(self, obj):
        if obj not in self.tracked_objs:
            self.tracked_objs.append(obj)

    def add(self, obj):
        self.store.add(obj)
        self.track(obj)

    def revert(self):
        self.tracked_objs.reverse()
        for obj in self.tracked_objs:
            self.store.remove(obj)
        try:
            self.store.commit()
        except:
            print "++++ exception on reverting changes ++++"
            print "Tracked objects:  %s" % self.tracked_objs
            raise
        self.tracked_objs = []

The idea being that when I add an object to it, it will be created in
the database.  When I call the revert method, the objects should be
removed from the store.  The thing is that the dependency handling on
DELETEs doesn't seem to work as well as it does on INSERTs.  In other
words, when I add something to the store, it will automagically flush
the object that other objects have references to first.  Thus, I don't
have to worry as much about foreign key constraints being broken.

However, with DELETEs the store seems to flush them in the order they
were removed from the store.  Thus, the row tracker I posted above
will remove objects from the store in *reverse* the order they were
added.  This works in a lot of cases, but still isn't perfect.  What
would be ideal is if it would handle dependencies in reverse the order
they're handled with INSERTS.

Is there any way around this?  Could this be a problem with the Oracle
backend somewhere?  Or could this be a problem with the particular
version of trunk we're using?