On Jan 30, 12:51 pm, "Michael Bayer" <[EMAIL PROTECTED]> wrote: > On Jan 30, 2:35 pm, "Ian Kelly" <[EMAIL PROTECTED]> wrote: > > > > > Finally, note that I'm _not_ asking for sqlalchemy to maintain the > > > > collections for me. All I'm asking is for the cascade code not to > > > > attempt to delete objects that have already been deleted and flushed, > > > > or at least to safely handle the exception it raises when it does. > > > > OK, what behavior are you looking for ? it raises an exception right > > > now. whats "unsafe" about it ? > > > Well, it interrupts the cascading and leaves session.deleted in an > > inconsistent state where not all of the object's dependents may be > > included. > > if that were true, thats a bug. can you illustrate this ? the > "deleted" collection on the unit of work is never altered in any way > until a flush() completes successfully. in theory, the state of your > program after an unsuccessful "flush" should be identical to that of > before the flush. this is one advantage to SA's "we dont change your > structures" approach - not only is it a huge beast to manage the > altering of structures, but we'd have to be able to roll the whole > thing back too.
This happens as a result of a failed session.delete() operation. The flush itself appears to be fine. If you still want an example, I can whip one up. --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
