For the quick users. What do you think about adding another key to the

eventData

argument for the

postSave()

interception point. The key would be the action (either insert or update). I hook into this event often and need to know if I working I am working with a new or existing entity.

There are

postInsert

and

postUpdate

events for you in these cases.

Im aware of those but it would be nice as far as refactoring code or code duplication goes. Just a thought

In most cases I think the current approach is quite clean with separate events for all three cases. But if you really want to know what’s happening you could set some generic identifier for updates or inserts in your postUpdate and postInsert interceptions and read this values in the postSave. This should be possible because the postSave is firing AFTER the postInsert or postUpdate. Up to you if you store this info in some property of your entity or in the prc. You could even call your own interceptor in the postInsert or postUpdate with all info you need. You only have to write your postInsert and postUpdate once, and you can focus on your postSave or your own interception in your code duplication and refactoring scenario’s once. This might sound like a bad idea, but your not changing anything in quick itself, and still get what you want with just a few lines of code.