Storm does not use references to order flushes of deletes

Bug #241530 reported by James Henstridge
2
Affects Status Importance Assigned to Milestone
Storm
New
Low
Unassigned

Bug Description

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.

Changed in storm:
importance: Undecided → Medium
Revision history for this message
James Henstridge (jamesh) wrote :

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.

Changed in storm:
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.