I'm not 100% sure that's what was going on (it was hard to get a debug shell open at the moment of the error, as opposed to the assertion much later), but switching those setattr() calls to set_committed_value() certainly fixed it.
I admit I don't understand the session internals well enough to grok what you're saying about resetting session.dirty or it being a deeper bug I've uncovered. If I can be of any assistance with that please let me know. Regardless, for this project it is no longer an issue as objects are no longer getting dirtied by setattr() calls in the mapper extension. Thanks for your help in pointing me down the right track; I'm pushing out a new version of SQLAlchemy-ORM-tree momentarily. Cheers, Mark On Tue, Oct 2, 2012 at 1:38 PM, Michael Bayer <[email protected]>wrote: > oh, I know what you're doing, you're modifying the attributes of objects > that aren't even involved - so yes, the flush normally doesn't go finding > those, and set_committed_value() would be your workaround for now. > > However, I can modify flush to do this "reset" for everything that's in > "dirty", rather than just what it knows to have changed. I'd have to > think about this as I'm not sure it's appropriate. > > > > On Oct 2, 2012, at 4:28 PM, Mark Friedenbach wrote: > > Indeed, session.dirty is non-empty within after_flush_postexec(). > > I'm working on a fix for sqlalchemy-orm-tree first before I can think > about doing a (smaller) regression test. Besides, it now occurs to me that > in some cases I might be setting attributes on objects in the session but > outside of the flush plan (child nodes of a parent that gets moved around, > for example). That could legitimately cause an undesired 2nd > flush. `set_committed_value` looks like what I want to fix that. > > On Tue, Oct 2, 2012 at 1:08 PM, Michael Bayer <[email protected]>wrote: > >> >> On Oct 2, 2012, at 4:05 PM, Michael Bayer wrote: >> >> > In theory it would be only .new and .dirty that might have state >> after the flush completes. >> >> correction, ".new and .deleted" lists that might have any state. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to [email protected]. >> 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. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > 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. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to [email protected]. > 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. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
