Storm does not use references to order flushes of deletes

[James Henstridge]

Take the following Storm classes

    class Foo(object):
        __storm_table__ = "foo"
        id = Int(primary=True)

    class Bar(object):
        __storm_table__ = "bar"
        id = Int(primary=True)
        foo_id = Int()
        foo = Reference(foo_id, Foo.id)

Assume that we have a database level foreign key constraint to match the above definitions. When adding objects, Storm makes sure that they are flushed in the right order:

    foo = Foo()
    bar = Bar()
    bar.foo = foo
    store.add(bar)
    store.flush()

But we don't do anything similar for removing objects:

    store.remove(foo)
    store.remove(bar)
    store.flush()

If the DELETE statement to remove foo is executed before the one for bar, then we'll get an IntegrityError. The same happens if we removed foo and changed bar:

    bar.foo = None
    store.remove(foo)
    store.flush()

Again, if the DELETE statement for foo is executed before the UPDATE statement for bar, we get an IntegrityError.

[James Henstridge (jamesh)]

Changing to low importance, since Gustavo's advisory flush ordering patch reduces the chance of hitting the bug: if the deletes are done in the right order then they should be flushed in that order.