when the many-to-one side is set, and the one-to-many isn't loaded, the object on the backref side is put into a special place called "pending collections", that is, things that are added or removed to the collection, but without actually loading the collection. this allows us to keep track of how to determine the history correctly once the collection is loaded, but without loading the collection, it's just a list of "added" or "removed" which may or may not differ from what the database has to say. So within this collection, there isn't a plain "history" to be reported though there is a way to see these objects using private APIs.
When after_flush() proceeds, the ORM goes through an enormous amount of effort to never emit SQL when it doesn't have to. When the unit of work is emitting SQL that isn't needed, it's a performance issue that affects thousands of users. So this particular collection, as it was never loaded and the flush only needs the many-to-one side to do its work, never gets loaded. The net effect is that the Chapter() object gets persisted. Then, after the flush, your event gets called. But there's no way to view a "history" here, since the thing that we see in the "pending collection" matches what we get from the database, if we use an active history fetch. The upshot is that it's not possible to get this data in after_flush without the load occurring ahead of time. So add a before_flush() method that iterates through everything and loads all collections you care about, then they should be present by the time you get to after_flush(). -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
