Yes, the passive_deletes='all' solves this, the trick is to put it in the backref (I was putting it in the forward relation).
On Oct 29, 8:29 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote: > Michael Bayer wrote: > > >bojanbwrote: > > >> On Oct 29, 5:32 pm, "Michael Bayer" <mike...@zzzcomputing.com> wrote: > > >>> how would the UOW "honor" RESTRICT ? if you tell it to delete a > >>> parent, > >>> and you didn't tell it to delete a child, and you have a non-nullable > >>> FK > >>> or RESTRICT, you'd expect it to....throw an error, right ? isn't that > >>> what happens here ? > > >> Well I don't know if we understand each other. If I have a ForeignKey > >> defined with ondelete='RESTRICT', and I delete the parent, no errors > >> are thrown. > > >> This only becomes apperent when you have a foreign key that is NOT > >> defined as non-nullable. Even if you define it to be non-nullable, the > >> error thrown when you try to delete the parent is not "update or > >> delete on table <parent_table> violates foreign key constraint", but > >> "null value in column <child_column> violates not-null constraint". > > >> I've created a ticket (http://www.sqlalchemy.org/trac/ticket/1594) > >> with more details and a test case to make it clearer. > > > thanks for this. > > correcting myself, the feature is already present (and is documented): > > mapper(Person, persons, properties={ > 'country': relation(Country, backref=backref('persons', > passive_deletes='all'), passive_updates=True)}) > > :param passive_deletes=False: > Indicates loading behavior during delete operations. > > A value of True indicates that unloaded child items should not > be loaded during a delete operation on the parent. Normally, > when a parent item is deleted, all child items are loaded so > that they can either be marked as deleted, or have their > foreign key to the parent set to NULL. Marking this flag as > True usually implies an ON DELETE <CASCADE|SET NULL> rule is in > place which will handle updating/deleting child rows on the > database side. > > Additionally, setting the flag to the string value 'all' will > disable the "nulling out" of the child foreign keys, when there > is no delete or delete-orphan cascade enabled. This is > typically used when a triggering or error raise scenario is in > place on the database side. Note that the foreign key > attributes on in-session child objects will not be changed > after a flush occurs so this is a very special use-case > setting. > > --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
