On Wednesday, December 19, 2012 12:29:50 PM UTC-5, Michael Bayer wrote: > the Session uses the method session._is_clean() internally to check if > going through the flush() steps is warranted, which is roughly equivalent > to the check you're doing, though it is doing less work to make this > decision >
_is_clean() looks perfect, thanks! > There's another caveat, which is that even if _is_clean() is false, that's > not a total guarantee that SQL will be emitted on flush. If you changed > one object attribute to be the same value that it already was, for example, > that's a "dirty" event, but when the flush runs through, it will see no net > change and not emit an UPDATE. > No problem... this is actually perfect since it still means that someone *tried* to alter something in the session, which is what I'm really after. > This is part of the reason _is_clean() at the moment still has an > underscore. Easier to keep the underscore than to promise a completely > predictable usage pattern :). > I'm fine with that, too... as long as the other "part[s] of the reason" for the underscore don't end up at "this method is totally not reliable for use in future versions since it could change at any time." :) Russ -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/4kgsie66ewMJ. 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.
