On Wednesday, January 12, 2011 2:16:00 PM UTC-5, Michael Bayer wrote: > > Suppose a concurrent thread or process deleted your row in a new > transaction and committed it, or didn't even commit yet hence locked the > row, in between the time you said commit() and later attempted to access the > attributes of the row. That's the rationale in a nutshell. >
Thanks, this make sense. For my purposes (where business logic ensures no post-commit shenanigans) on this one I can just snag the id after a pre-commit flush() and that will be fine. For my issues with object detachment I'll post another topic. -- 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.
