CRUD result callback for persistent classes

Question

Question

Mathew Lambert · Jun 16, 2020

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

Discussion (8)1

Log in or sign up to continue

Mathew Lambert · Jul 7, 2020

As it seems that there is not the possibility to do this as of now, we will be talking with InterSystems.

0 0

score 1 · Answer 1 · 2020-06-16T07:58:40-04:00

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

score 0 · Answer 2 · 2020-06-16T08:09:46-04:00

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.

score 1 · Answer 3 · 2020-06-16T08:37:38-04:00

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

score 0 · Answer 4 · 2020-06-16T08:45:18-04:00

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

score 1 · Answer 5 · 2020-06-16T08:59:00-04:00

Ah, getting closer:
The problem seems to reduce to an alternative way (a wrapper around) to %Open and %Delete.

score 0 · Answer 6 · 2020-06-16T08:41:35-04:00

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

score 1 · Answer 7 · 2020-06-16T08:43:45-04:00

it isn't the save yet. especially if some UNIQUE conflict prevents the save and requires a Rollback
delete isn't affected at all