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?
There are certain states a persistent record reaches where further
changes to
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
On 12/15/2011 12:20 PM, Michael Bayer wrote:
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
On Dec 15, 2011, at 1:16 PM, Kent wrote:
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
On 12/15/2011 1:31 PM, Michael Bayer wrote:
Are there reasons one need to avoid referencing unloaded relationships from
within before_upate()? (I can't recall the exact problem I've had in the past
with that at the moment.)
Thanks for all the input. Regarding the issue of referencing a
On Dec 15, 2011, at 2:13 PM, Kent wrote:
On 12/15/2011 1:31 PM, Michael Bayer wrote:
Are there reasons one need to avoid referencing unloaded relationships from
within before_upate()? (I can't recall the exact problem I've had in the
past with that at the moment.)
Thanks for all the
