[storm] Deletion questions

[Leonardo Rochael Almeida]

When specifying referential integrity in postgres, you can specify
that it be checked only on commit. This way you can do a bunch of
temporarily-integrity-breaking changes inside a transaction without
complaint as long as your final database state passes the integrity
check.

Cheers, Leo

On Thu, Oct 23, 2008 at 07:20, Morten Siebuhr <sbhr at sbhr.dk> wrote:
> Hi,
>
> I've hit some problems when deleting (i.e. store.remove()) objects from
> the store and reference integrity (only applies to PostgreSQL - all
> other tested engines does not fail on this).
>
> My application maintains a list of users, their computers, NICs, where
> the computers have a foreign key to the owners' userid and the NICs have
> one for the computer they're in.
>
> When I remove a user from the system, I build a list of objects to
> delete, i.e.:
>
> delete = [user]
>
> for computer in user.computers:
>    delete.append(computer)
>    for interface in computer.interfaces:
>        delete.append(interface)
>
> if not ask_user("Do you want to delete %d items?" % (len(delete)):
>    return
>
> delete.reverse()
> for del_item in delete:
>    storm.remove(del_item)
> storm.commit()
>
> When I get to the commit, it usually fails with a integrity/foreign key
> error, as the objects are flushed in a different order than I call
> delete on them.
>
> What is the best way to get around this? Call store.flush() after each
> store.remove(xx), or store.add_flush_order(last_xx, xx) for each item,
> or something completely different? How will Storm react if I use
> cascading deletes?
>
> Regards,
> /Morten Siebuhr
>
>
> --
> storm mailing list
> storm at lists.canonical.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
>