That sounds like it could be very useful for me, thank you for pointing me there. That could solve one of the two issues I'm facing that I listed... what about the other?
On Apr 29, 11:02 am, "Michael Bayer" <mike...@zzzcomputing.com> wrote: > Kent wrote: > > Before saving objects to the database, we have need to inspect the > > changes. I am aware of the attributes.get_history() functionality, > > which is helpful to a point. > > > attributes.get_history() falls short of what I need in two places: > > *** after a session.flush(), it is gone. There are times we need to > > flush, but the transaction has still not been committed, and more > > processing is required, so we still need access to the history of > > changes for this object in this transaction despite a call to flush(). > > *** if there are calculation methods I've written that objects have, I > > need to be able to call these for the "old" object. For example, say > > I write a method on Order class such as "def > > calculate_total_volume(self):" When an order is saved I need to > > compare the old volume to the new. On the merged order, I can call > > "merged_obj.calculate_total_volume()", but I would need to use the > > information in attributes.get_history() to *recreate* the "old" > > version of the object in order to call > > "old_order.calculate_total_volume()" > > > I've realized that if merge() attached a python attribute, such as > > "_original" (which is a transient clone of the object fetched from the > > database) to each object as it merges it, then this > > * would be accessible regardless of session.flush() > > * could be acted on with object methods like any other object > > * is probably more intuitive than "attributes.get_history()", > > especially to those familiar with Oracle triggers and :OLD.orderid > > vs :NEW.orderid. This would be very similar: "merged.orderid" vs > > "merged._original.orderid" > > > Disadvantage: > > * it goes against the concept of trying to be very hands-off on the > > actual object. Maybe it could instead be stored in the instance's > > state or something. > > > Does this conceptually make sense? Does it make enough sense to make > > this a feature? > > > In the meantime, can you recommend an approach for me? (Extend the > > Session class?) > > you want to be using a SessionExtension here, and the "after_flush()" hook > is provided precisely for the use case that you want rules to execute > after SQL has been flushed, but you still want a full accounting of > everything that has changed - the attribute history on all objects has not > yet been reset at this point. The information available in after_flush() > is unique in that it also includes any foreign key values that have been > synchronized from parent to child over relationships. > > > > > Thanks much, > > Kent > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To post to this group, send email to sqlalch...@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. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://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 sqlalch...@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.
