Brad Clements wrote: > given a one-to-many, and the one is deleted I want the many's to be set > null. > > How do I specify that in a relation cascade rule? > > cascade="null-orphan" ?
for the many's to be set null, thats what it does by default, when you detach the child object from the parent, or delete the parent and not the child; the child's foreign key column just gets set to null. it only deletes both parent/child rows if you mark both parent and child objects deleted and flush(). the "cascade" rule that does "delete,delete-orphan" is a shortcut for "delete the child when the parent is deleted, or delete the child when its detached from the parent". but in this case you dont want that, so just leave cascade at its default (which is "save-update"). > > and does save-update mean the same as "on update cascade" ? save-update means, "when the parent is saved or updated into the Session, then do the same for the child. or, if a child is attached to a parent that is already part of a session, then do save/update for the child as well". it has nothing to do with the "on update" SQL operation. > I am having trouble relating these cascade rules to sql referential > integrity > specifications. referential integrity should be completely maintained in the absense of cascade rules. cascade rules are just a convenience feature for marking things as part of a session to be "inserted" or "updated", or marking them as "deleted"...which you can do completely programmatically for each object explicitly, not using any cascade stuff at all; cascading is a session-management feature. in a sense, a deleting cascade is somewhat related to a foreign key column that is not nullable (i.e. child rows must be deleted along with parent rows), but thats about it. > > And, what if I want the database to handle it, how can I specify that "on > delete set > null" will be used for a foreign key, and will sqlalchemy realize that it > has to > update it's session identity map in this case? adding "on update/on delete" clauses to table create statements is part of a pending ticket in trac. and no, sqlalchemy will have no idea that an on update/on delete fired off. usually, if you have your mapping relationships set up appropriately, sqlalchemy will have performed the appropriate update/delete operations before it hits the actual table that has the onupdate/ondelete rule set on it, for those objects that are in the session. for objects that have not been loaded at all into the session, the database's onupdate/ondelete rules will fire off; and since those objects arent in the session, it doesnt matter that SA doesnt know about them. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
