Alexandre CONRAD wrote:
> 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 ?

theres an FAQ entry on this, basically everything should work just fine
since SA will issue DELETE statements for the rows in the proper order
before the "ondelete" ever gets triggered.  it also means that  other
rows in the DB which may have not been loaded into memory get properly
deleted too.  I might look into adding some relation options for this,
regarding "do i load in the full list of child items for a DELETE so
that i know what rows to delete?".  right now its a little murky
whether or not it does that, it should be more explicitly defined.

>
> 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...

theres no right way to do it, both ways, or a combination, is fine.
deleting is not what most applications spend most of their time doing,
and we still have to handle all the INSERTs, UPDATEs (since ON UPDATE
is generally only when primary keys change, which SA doesnt handle
directly...).   SA was written without ON DELETE in mind too heavily,
and ORM's like HIbernate dont account for it at all AFAICT,  but
generally each of the two approaches shouldnt conflict too much.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sqlalchemy
-~----------~----~----~----~------~----~------~--~---

Reply via email to