On Aug 28, 2014, at 1:27 PM, Chad Dombrova <chad...@gmail.com> wrote:
> Thanks again for the help. > > your code isn't working because somehow you've dug in and bypassed all the > public history APIs to find one that is internal to the flush context and is > actually cached. > > The docs for after_flush link to the docs for UOWTransaction, which is where > I found the info on get_attribute_history: > http://docs.sqlalchemy.org/en/latest/orm/internals.html#sqlalchemy.orm.session.UOWTransaction > > The docs have very little practical info on how to access interesting data in > an after_flush event, and google has not turned up any example code, so > hopefully this gist that I'm building up will help some people out. > > I've updated my gist to demonstrate another problem: even when using > load_history() the remote side of a many-to-one relationship is not updated. I looked for a second and I have a feeling you're looking for the "old" value. Set active_history=True on the many-to-one relationship or backref, and it will emit this typically unneeded load when you assign a new value to a many-to-one. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
