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. There is only one exception to this now that i think about it, and its that foreign key-holding attributes on objects may have had their values modified (i.e. scalars), but i cant see how that would affect anything, including a subsequent flush(). is this the problem youre observing? also, the usual strategy when a flush() fails is to throw away the session and start over again. this is a little bit web-centric but im curious to see how your program is actually failing. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
