> The same is true of FOREIGN KEY, by the way (I checked), but that's a bit > more obvious since breaking FOREIGN KEY will always result in a database the > programmer would consider corrupt.
You're not quite right. You're talking about immediate foreign keys. There're deferred foreign keys too. See section 4.2 here: http://www.sqlite.org/foreignkeys.html. Pavel On Wed, Nov 25, 2009 at 9:13 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 25 Nov 2009, at 2:06pm, Pavel Ivanov wrote: > >>> I couldn't find the answer documented anywhere, so I will have to assume >>> that it may change in future versions. Unless the requirement for depth >>> first is somewhere in the SQL specification. >> >> I believe it should be. Triggers should be executed before the >> statement causing them to fire is considered successful. Otherwise all >> triggers checking some constraints and prohibiting incorrect data (and >> thus raise(...) function) are useless. > > Ahha. That makes sense: it would have to RAISE an error and back out the > other transactions anyway, so it may as well do the TRIGGERs first. Okay, on > that basis I can write my code assuming that it will always behave > depth-first. > > The same is true of FOREIGN KEY, by the way (I checked), but that's a bit > more obvious since breaking FOREIGN KEY will always result in a database the > programmer would consider corrupt. I wrote some code in another DBMS once > that betrayed that it did some really nasty things when one FOREIGN KEY > triggered another one. > > Thanks for the help. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
