Subject | RE: [Firebird-general] FB2 Read Only fields in triggers |
---|---|
Author | Roger Vellacott |
Post date | 2006-07-15T08:49:42Z |
Dmitry,
Thanks for this full and informative reply.
Roger Vellacott
Passfield Data Systems Ltd
-----Original Message-----
From: Dmitry Yemanov [mailto:dimitr@...]
Sent: 15 July 2006 05:33
To: Firebird-general@yahoogroups.com
Subject: Re: [Firebird-general] FB2 Read Only fields in triggers
"Roger Vellacott" < rvellacott@passfiel
<mailto:rvellacott%40passfield.co.uk> d.co.uk> wrote:
restorable.
causing
database corruptions in the past. And I cannot guarantee all those bugs
are
fixed now.
Second, this feature brings some confusion and causes hidden errors in
the
trigger logic. I know a few projects that already discoved buggy usage
of
context variable in their triggers with the help of this new FB2 check.
When
you have many before and after triggers, it's very easy to confuse them
and
put an assignment to NEW in the AFTER-trigger. And you'll never be
warned
until your trigger starts to work wrongly.
If you want temporary storage, use local variables. They exist exactly
for
this purpose. IMO, replacing them with the NEW row just makes the SQL
code
less understandable.
Dmitry
Thanks for this full and informative reply.
Roger Vellacott
Passfield Data Systems Ltd
-----Original Message-----
From: Dmitry Yemanov [mailto:dimitr@...]
Sent: 15 July 2006 05:33
To: Firebird-general@yahoogroups.com
Subject: Re: [Firebird-general] FB2 Read Only fields in triggers
"Roger Vellacott" < rvellacott@passfiel
<mailto:rvellacott%40passfield.co.uk> d.co.uk> wrote:
>Why did you rely on this implementation artefact? It's not documented.
> We have used these fields as local variables in a lot of places
> FB2 seems happy to accept scripts which include the error..No, it throws an error. Although backups with this error can be
restorable.
> Is there a good reason for the change?First, assignments to the OLD context were proven as unreliable and
causing
database corruptions in the past. And I cannot guarantee all those bugs
are
fixed now.
Second, this feature brings some confusion and causes hidden errors in
the
trigger logic. I know a few projects that already discoved buggy usage
of
context variable in their triggers with the help of this new FB2 check.
When
you have many before and after triggers, it's very easy to confuse them
and
put an assignment to NEW in the AFTER-trigger. And you'll never be
warned
until your trigger starts to work wrongly.
If you want temporary storage, use local variables. They exist exactly
for
this purpose. IMO, replacing them with the NEW row just makes the SQL
code
less understandable.
Dmitry