I've been finding this discussion quite interesting. I have not
analysed the ramifications of change-capable read triggers as deeply
as Chuck but my "gut" says allowing such behaviour is wrong.
On 29/03/2008, at 6:33 AM, Peter Dow (ML) wrote:
I hope you're not feeling picked on here! I'm still having a hard
time
understanding your objection and some of your explanations.
CRPence wrote:
No. Insert Trigger act between the trigger program and the
database;
they have their own contractual obligations. A Read Trigger is
between
the HLL and the database. That is what makes them totally different.
What does this mean? From the app pgm point of view, all of these
triggers -- READ, INSERT, UPDATE, DELETE -- are between it and the
database.
The difference is one of control (or perhaps direction). Conceptually:
Add, update, delete trigger:
Application program
Database
Trigger program
Database -- database has control and can validate data received
Read trigger:
Database
Trigger program
-- trigger receives copy of buffer therefore database maintains
control
Database
Application program
Read trigger with change capability:
Database
Trigger program
-- trigger receives direct buffer access therefore database cannot
control what is received by application program (could be data
entirely unrelated to the row just read)
Database
Application program
Or perhaps:
Application hands data to trigger, trigger hands data to database,
database validates against type, constraints, etc.
versus:
Database hands data to trigger, trigger hands data to application,
application ???
Seems to me that the fundamental difficulty in understanding this is
simply because Chuck (and I) consider trigger programs to be part of
the database. I think that those arguing FOR change-capable read
triggers consider the trigger program to be part of the application.
This is wrong (and propagated by IBM examples in Redbooks and
Education where triggers are used to extend application behaviour
such as faxing order confirmations etc.). Trigger program should be
used to extend database functions either not currently implemented or
restrictive (e.g., referential integrity checks based on logic
decisions). Just because you CAN use a trigger to circumvent/solve
application issues doesn't mean you should.
An *AFTER add, update, or delete trigger cannot change the data
buffer because the database has already done the work.
Applying the same "rule" to a read trigger implies that it should not
be able to change the data because database has completed the work of
"reading" the record/row.
A *BEFORE add, update, or delete trigger can change the data because
database gets a chance to validate any junk (within the current
constraints that allow certain types of junk) thus reducing the
chance of garbage in the database.
A read trigger fires *AFTER database has handed over the data.
Database no longer has control over what is given to the application
program. Because triggers are part of the database this is obviously
wrong therefore database maintains control by giving the trigger a
**COPY** of the data and upon return from the trigger database
provides the original "known good data" to the application.
Now, one COULD argue that ensuring correct data is supplied to the
application is the responsibility of the trigger program author. It
is obvious from these lists that many programers have trouble with
basic concepts of parameter passing (specifically data lengths),
stream processing, binding, service programs, etc. Imagine the
problems caused if they now have to accept responsibility for
ensuring data buffers supplied to an application are correct?
IBM Support: Hello. Your customer number please ....
Customer: My program is getting junk data on a READ.
IBM Support: Do you have a read trigger active?
Customer: Don't know?
IBM Support: Use DSPFD to check.
Customer: Um, yes we do.
IBM Support: Then sod off and stop bothering me! (Except they'd be
much more polite and would probably go through the exercise of
removing the trigger and trying the application again and then THEY
SHOULD BILL FOR CUSTOMER STUPIDITY. I'm sure there's a ConsultLine
line item for that.).
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
