RE: [Firebird-devel] invalid check/trigger order

[Claudio V. C. <cv...@us...>]

> -----Original Message-----
> From: fir...@li...
> [mailto:fir...@li...]On Behalf Of
> Dmitry Kuzmenko
> Sent: S=E1bado 29 de Septiembre de 2001 5:22
>
> Hello, All!
>
> I've reported
>
> https://sourceforge.net/tracker/?func=3Ddetail&aid=3D444463&group_i=
d=3D9
> 028&atid=3D109028
>
> 07/25/2001, but seems that nobody interested?

Could you consider the option that volunteers have other pending task=
s or
are doing their own regular paid work to make a life, too?

If there are a lot of people, they could consider (and this is not a =
flame
nor a bad joke) to give FB a contribution and chip in a few pennies (=
with
enough people donating small quantities, they will get a reasonable a=
mount),
then contact Mark O'Donohue for a prompt fix from FB Professional Ser=
vices.


> Need to say, that IB 5.6 had
> correct order of checks and triggers, that's why people found that
> migrated applications started to work wrong. Most of them returned =
to 5.6,
> and still can't use neither IB6, nor Firebird.
> The main disadvantage of this "new v6" feature is that database can=
 be
> made unrestorable.

I posted this a couple of days ago, where were you? (Ok, you were in =
Russia.
<g>) I thought naively that the issue had been solved since nobody co=
mmented
on it:

-----Original Message-----
=46rom: fir...@li...
[mailto:fir...@li...]On Behalf Of Claud=
io
Valderrama C.
Sent: S=E1bado 15 de Septiembre de 2001 2:45
To: fir...@li...
Subject: RE: [Firebird-devel] (WARNING: VERY LONG) Table structures a=
nd gbak

[BIG SNIP HERE]

Speaking about strange bugs, someone claimed that FB won't work prope=
rly
with "before insert" triggers v/s check constraints because the latte=
r will
be executed first. Therefore, a check constraint validates a field, t=
hen the
before-insert trigger can change such value and on backup/restore,
restoration will fail. This is what I remember from the post, but I s=
ee the
following comment in DFW.E:

/* BUG #8458: Check constraint triggers have to be loaded
              (and hence executed) after the user-defined
=09      triggers because user-defined triggers can modify
=09      the values being inserted or updated so that
=09      the end values stored in the database don't
=09      fulfill the check constraint */

and there's code to make sure CHECKs are loaded after other triggers.=
 Or
does this issue manifest itself only of the check constraint is imnpl=
emented
at the level of an explicit DOMAIN, I mean only with
create domain d0 int check (value > 0);
create table t0(a d0, b char(10));
or what? Is the person that wrote about the bug here?

A thing I dislike in the code is that an index is assumed to be forei=
gn if
it carries the
RDB$FOREIGN prefix in its name and an "implementation-helper" trigger=
 that
implements a check constraint is assumed to be such kind if it carrie=
s the
CHECK_ prefix in its name. When I built my own metadata extraction st=
uff, I
did a more complex and slower, multi-table join but I made sure I was
getting the right thing instead of relying on names. You can use
relation_constraints and ref_constraints to be accurate. If someone d=
ecides
to rename the FK index, problems may arise:
    FOR (REQUEST_HANDLE request)
=09IDX IN RDB$INDICES CROSS
=09IND IN RDB$INDICES WITH
=09IDX.RDB$INDEX_NAME STARTING WITH "RDB$FOREIGN" AND
=09IDX.RDB$RELATION_NAME EQ relation->rel_name AND
=09IND.RDB$INDEX_NAME EQ IDX.RDB$FOREIGN_KEY AND
=09IND.RDB$UNIQUE_FLAG NOT MISSING

In the second case, I think that if someone writes a trigger named
CHECK_<something> by mistake (by not having insider information, do I=
 need
it if I'm an app developer?), the current code may be defeated:
FOR (REQUEST_HANDLE request_fmtx)
=09TRG IN RDB$TRIGGERS
=09WITH TRG.RDB$RELATION_NAME =3D work->dfw_name AND
=09(TRG.RDB$SYSTEM_FLAG =3D 0 OR TRG.RDB$SYSTEM_FLAG MISSING)
=09AND NOT (TRG.RDB$TRIGGER_NAME STARTING WITH 'CHECK_'
=09    AND  TRG.RDB$TRIGGER_SOURCE MISSING)
=09SORTED BY TRG.RDB$TRIGGER_SEQUENCE

I'm still looking for the place where check constraints at the domain=
 level
are loaded, since they should be executed after user triggers, too. A=
nn, any
hint?

C.