Re: Anyone using Triggers to enforce data validation & business rules?

On 9/23/2014 11:28 AM, Nathan Andelin wrote:

@Buck, I'm not sure what you mean by the call stack being immutable.
Are you saying that your Triggers are only evoked via RLA via 5250
applications which you control?

No, the trigger can be fired via ODBC, CGI, JDBC and who knows what
else. That's why there is value moving business logic into the trigger
vice application code.

I used that rationale myself for a long time. I would just perform
data validation and RI constraints in DB I/O service programs bound to
multiple RPG applications. Why employ Triggers at all if you already
employ MVC design - I thought.

After a long period of time I began to believe that I was holding on
to an unnecessarily narrow computing paradigm. Database utilities have
become so robust that they are replacing legacy database maintenance
applications. Database updates are occurring via QZDASOINIT, QSQSRVR,
and other SQL interfaces. PHP Applications are performing DB I/O via
XMLService, which might alternately be evoked via HTTP CGI or QSQLSVR
interfaces, depending on switch settings.

In that context, it seems to me that the owner of the Trigger wouldn't
know how far up the call stack to send *Escape messages.

No, the sender is still always 3 call stack levels away (in my design)
no matter what I/O operation fires the trigger. I have the program
doing the I/O, the trigger, and the subprocedure sending the message.

For me, the discussion of communicating between Triggers and
Applications via QMHSNDPM and QMHRCVPM message interfaces is losing
value. If a Trigger invalidates a record because the value in the
Email column is blank - the application needs to know the name of the
column that is being rejected in order to position the cursor on that
field and highlight it, etc.

Applications that go through ODBC, JDBC, and similar interfaces very
often display what appears like a core dump when database errors occur
- what a joke.

Placing data validation and RI constraints in modules that are
guaranteed to be evoked by all types of applications makes sense. But
applications need better interfaces than *Escape messages.

Yes, the escape message is just the signal that the I/O program needs to
do some work to find out what happened. If there is value to this
discussion, it's not necessarily the specifics of how to transmit that
information from the trigger to the I/O, but that EVERY I/O operation is
subject to escape messages from triggers, RI violations and perhaps
RPGOA operations. Very few RPG programs will gracefully handle I/O
exceptions but in 2014, they should.

When it comes to feedback from a business logic trigger to say, JDBC,
how will the ILE public data structure export help?
--buck