Michael Bayer wrote: > ForeignKeyConstraint is a table-level definition, ForeignKey is a > column level. If you have just a single ForeignKey on a single column, > they are equivalent. for a composite foreign key, ForeignKeyConstraint > gives you the extra verbosity needed (i.e. its exactly analgous to > SQL's FOREIGN KEY clause which can be placed on a column or on the > table overall). > > "on_update" within ForeignKeyConstraint will place a "ON > UPDATE=<something>" directive on your table's DDL definition. This is > SQL level cascading and is described: > > http://www.postgresql.org/docs/8.1/interactive/sql-createtable.html > (scroll down to "REFERENCES reftable [ ( refcolumn ) ]") > > the thing that "cascades" here is the update of a column value, such as > UPDATE <sometable> SET x=5. > > the "cascade" flag on relation() also relates to the "cascading" of > data along a relationship, but is talking about a relationship between > two objects, and refers to various session operations such as save(), > update(), delete(), etc. > > the thing that "cascades" here is a session call such as > session.delete(x). > > so the term "cascade" refers to a general class of behavior (traversing > along some kind of relationship), but has two totally different > meanings in context (your database tables vs. a SQLAlchemy session > object)
So if I understand well, ForeignKeyConstraint's "onupdate" argument is at the database level. Meaning you don't have to worry about SA's "on update" and "on delete" as this job is handled by the database it self, internally. Eg, when a parent is deleted by SA, all childs refereing to that parent would also be deleted by the *database* itself, as this is how the relation rules were designed at the database-level. Right ? On the other hand, without any database-level "action" rule, SA handles "onupdate" and "ondelete" within a session object. Meaning that when SA will delete a parent object, is also has to send *extra* DELETE commands to every refering childs so they are as well deleted. What would happend if SA's "ondelete" is contradictory to the database's action rules ? If I understand, a database can be designed "freely" without any action contraints between tables, and SA can handle this at a higher level, sending "manual" commands to the database, keeping track of what should be deleted. But shouldn't this be the database's job ? I know this gives extra flexibility. But I'm just wondering what's the right way to do it... I'm still learning a lot about databases in general (I'm pretty new to that). So I might be confusing. I just want to make sure I'm not misunderstanding "actions". I don't want to mix/confuse myself. Regards, -- Alexandre CONRAD --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~----------~----~----~----~------~----~------~--~---
