CRUD result callback for persistent classes
I would like to know if there is a way of having a callback or something similar, on persistent classes that is always called after the execution of the operation (failed or successfull).
%OnOpen is executed prior to the action, and there is no post callback
%OnAfterDelete and %OnAfterSave are executed after a successfull operation
Comments
take a look at %Library.Persistent. Methods
- %Open, %OpenId have a 3rd call parameter status that returns a %Status value indicating success or failure.
- %Delete, %DeleteId do it as direct result by a %Status value indicating success or failure.
No further need of an %On.... to know success or failure
I know how to obtain the status from the call, but I want to have a method that I can implement in an abstract class, that I inherit in all my persistent classes, and with very few lines of code I can track all CRUD operations.
As all you need is in %Persitent you could have your own personal.persitent extending %persitent
wrapping %Open and %Delete in your own extended code.
3 points to consider:
- how to force your personal.persitent to all existent and future classes ?
- how to force classes generated by DDL ?
- how to maintain your extension over release changes ?
Sorry, I doubt if this is the right approach
I'm trying to avoid wrapping %persistent methods because
- this could lead to problems between releses
- those methods are final (so I would need to wrap them in a different named method
Regarding your points, we don't generate classes via DDL and to force inheritance I would just implement a test and add it to our Persistent classes Best Practices.
Thank you
Ah, getting closer:
The problem seems to reduce to an alternative way (a wrapper around) to %Open and %Delete.
Hi Mathew,
I think that a unique single point to handle all CRUD operations does not exists. Maybe you can implement in the base class some Methods Generators to handle all situations that you need.
Below the documentation of all possible callback methods:
https://docs.intersystems.com/irisforhealth20201/csp/docbook/Doc.View.cls?KEY=GOBJ_callbacks
it isn't the save yet. especially if some UNIQUE conflict prevents the save and requires a Rollback
delete isn't affected at all
As it seems that there is not the possibility to do this as of now, we will be talking with InterSystems.