On Nov 12, 2010, at 7:49 PM, thatsanicehatyouh...@mac.com wrote: > Thanks for the quick reply! > > On Nov 12, 2010, at 7:41 PM, Michael Bayer wrote: > >> mm, right there that's not the default behavior. If you did an add(A), the >> next query() you do will autoflush. "A" is now in the database within the >> scope of the current transaction, so query() will find it. > > Yes, I have autoflush=False. A typical script for me is to load a batch of > files into our database. If there is any problem with processing any of the > files, I want the commit to fail - I don't want a partial import. I'd rather > fix the problem and do another batch import (because I don't want to write a > bunch of code checking how much was written and where to pick up from). I > definitely don't want a query() to be a write operation. > > Or is this a case where a nested transaction would be appropriate?
If the commit fails, then nothing is written to the database. The whole point of transactions is so that "partial" operations are not possible, even though you get to send your data to the database as its constructed, and you get the full advantage of SQL querying on that data without anything being permanent. It's truly the best of both worlds. Unless you're using MySQL + MyISAM, this would give you the behavior it seems like you're looking for. Nested transactions would be useful if you wanted to roll back partially within the same transaction and then try some operation again, but this is a more exotic need - your description that you'd want to "fix the problem then do another batch import" is what people normally would do, and shouldn't require anything beyond default Session behavior. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
