On Feb 15, 2014, at 11:38 PM, Jay Pipes <jaypi...@gmail.com> wrote: > Thank you Michael. Yes, that is indeed the case if I delete an object via > session.delete(). > > Unfortunately, it seems that if I execute the DELETE manually against the > table in question, that the delete does not cascade, as shown by this code: > > http://paste.openstack.org/show/66005/ > > Does this mean that cascades are only handled in the session and are not > handled by SQL schema constructs on the tables themselves?
DELETE cascades can be addressed in more than one way, and these ways can be combined. In relational databases, when we want a DELETE statement to cascade to rows which refer to this row, we use a DDL expression “ON DELETE CASCADE”: see “ON DELETE” at http://www.postgresql.org/docs/9.3/static/sql-createtable.html In SQLAlchemy, these options can be configured to emit at CREATE TABLE time using the ondelete option: http://docs.sqlalchemy.org/en/rel_0_9/core/constraints.html#on-update-and-on-delete note that if your tables already exist in the database, then these directives have no effect. The ORM can work with ON DELETE CASCADE by allowing the database to handle the delete operation, rather than the ORM emitting DELETE statements. However, it is often a good idea to let both systems work together, so that the ORM can apply the correct state to those rows which are already loaded in memory, and any rows that are not loaded can be handled by the database. Documentation on how to configure this integration is here: http://docs.sqlalchemy.org/en/rel_0_9/orm/collections.html#using-passive-deletes
signature.asc
Description: Message signed with OpenPGP using GPGMail
