Ah, I understand the reasoning now. Adding the flush in between the delete and add did just the trick; thank you for the explanation, Mike!
Andrew On May 19, 10:29 am, Michael Bayer <mike...@zzzcomputing.com> wrote: > On May 19, 2010, at 10:16 AM, Andrew wrote: > > > > > We're using ORM to do unit testing, so we're mocking up the commit > > message to do nothing, basically creating a long transaction that's > > rolled back at the end of the test. However, I am running into the > > following problem. Assume we've mapped a table to class MyTable with > > a varchar `name' and a boolean `flag' that defaults to false: > > > Session.add(MyTable(name="Bob")) > > bob = Session.query(MyTable).filter_by(name="Bob").first() > > bob.flag = True > > > Session.query(MyTable).filter_by(name="Bob").first() > > Session.delete(bob) > > > # At this point, Bob does not exist and doing a query *will* fail > > within the transaction > > Session.add(MyTable(name="Bob")) > > bob = Session.query(MyTable).filter_by(name="Bob").first() > > assert_equals(bob.flag, False) > > > This now fails with bob.flag still being set to True from the previous > > update, even though the default value in the DB is set to be False by > > default (and works correctly on the initial insert). Running this > > with commits turned on does not run into this problem. > > > Before submitting a bug, I want to make sure there's not a config > > setting somewhere that we're missing. We are running this against > > postgresql 8.4 with sqlalchemy 0.6. > > this is the expected behavior as a flush() that receives a delete() and > insert() of the same effective row (assuming "name" is the primary key here) > is converted to an UPDATE. If you put a flush() after the delete() of bob1 > the next add() would result in an insert. > > this behavior is due to the fact that the unit of work emits all > inserts/updates before all the deletes within a single flush. the UOW > rewrite of 0.6 broke the very first ground on us being able to make this > behavior more flexible, but such functionality is a long way off. > > -- > 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 > athttp://groups.google.com/group/sqlalchemy?hl=en. -- 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.
