On Dec 15, 2011, at 11:46 AM, Kent wrote: > I notice no such API events as before_expunge() or after_expunge(). > Hopefully without taking much of your time, can you point me in any > direction of how I might go about being notified when an object is > expunged? > > Why?
If we start adding events like that, it suggests we'd be adding a few dozen more hooks for before_/after_ pretty much every operation in the Session, essentially decorating every method - before_add(), after_add(), before_close(), after_close(), before_expire(), after_expire(), before_delete(), after_delete() etc etc right ? This would greatly clutter and clog the Session object and add latency. They'd also be difficult to define as there are cascades which take place - do the event hooks accommodate just the call of the method itself or also all the objects reached by a cascade ? The existing events are specifically to intercept places in the code that otherwise can't be intercepted - that is, deep within a series of steps. Intercepting public method calls is just as easily done with custom Session subclass, or using wrapper code within your own application. > > There are certain states a persistent record reaches where further > changes to it are forbidden and it becomes a "historical" record, for > example, for accounting purposes. For example, consider a closed > order, shipped, paid for, done. There are times, however, when I want > to re-run calculations on such objects to calculate a delta for > finances, etc. Suppose a discount were retroactively applied to this > order, such that you want to use existing code to rerun tax > calculations, etc for the closed order and inspect all the changes > without danger of it being persisted to the database. > > I am heading down the road of expunging objects that have reached this > "archived, historical" state so that I can still use the object for > all it's calculations and be assured that no changes will be persisted > to the database. (Another thought I had was using transient objects, > but I think the end result is similar) why not use a before_flush() extension, or similarly a before_insert/before_update/before_delete extension, and simply reject flush() calls which include such objects in the list of those to be modified ? The fact is they still represent database data and will work a lot better if they have access to their persistent state. > > My concern is that once such an object has been expunged, I don't want > any relationship or code or anything automatically reloading or > refreshing it from the database with session.query().get. you mean, because that raises an error on a detached , or because the objects represent in-memory-only state that should no longer reflect database state ? > My plan was > to record expunged objects on the session object so I could look them > up during reconstruct_instance() and raise an error if the same record > is being loaded from the database that I've already expunged. if you are going that approach I would just use a library call within your own app called "mark_as_historical()", which does the expunge() and also adds the element to the collection in question. This is functionality in addition to what expunge() does. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. 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.
