Subject | Re: Server Exceptions (was Re: [firebird-support] Is using SELECT COUNT (*) in a stored procedure a bad idea? (Once Again)) |
---|---|
Author | Alexandre Benson Smith |
Post date | 2004-01-27T23:49:08Z |
At 20:01 27/01/2004 +0000, you wrote:
It's an interisting idea...
I should trust your friend, but I don't bet that conflicts will not ocurr :)
I don't like the idea of be messing around with system tables...
The solution works (let's forget about conflicts that he swears does not
occurr), but to make the exceptions user friendly one should put all the
consistency logic in stored procs and triggers. I like the idea of have a
constraints declared in the tables (create table statement). When a FK is
declared an internal trigger is created to check this constraint, I don't
like the idea of duplicate it on SP's. I could do the checks on the client
(before send the data) but for the same reason I don't like the idea,
besides, AFAIK the trigger knows (in "some mystic way") about other
transactions data as explained why you can create a trigger to enforce
referential integrity for table that has no common change in the data and
not for table that are changed all the time.
Because I like the idea of having referential constraints declared in the
"create table statement" I live with the bad indexes created by FK's that
references small tables, until those indexes don't bring my system down, I
will wait for the FB feature that allows to disable such indexes.
If the server could send more detailed data about the exceptions, I could
format the exception message on the client side... And leave the
referential logic just on the server and decalred just on table creation time.
Thanks for your answer and your time... I like to see how people handle
such situations... Imagination to try diferent aproachs bring some
interesting ideas...
see you
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
[Non-text portions of this message have been removed]
> About making system exceptions more user friendly there is ratherHi Alexander,
>old and somehow naive article in Russian
>http://www.ibase.ru/devinfo/customex.htm. Idea is rather simple, you
>can skip text and look at script and usage examples. When it was
>discussed I objected - such a method should provide many lock
>conflicts on this pig-exception, but author (he is my friend, I know
>him as truthful person) swears he use it on heavy enough loaded server
>and never encountered lock conflict on exception processing. Seems in
>real life, for well-designed application which operate in short
>read_commited transactions, probability of coincedence of exceptions
>produced by different users is low. I did'nt tried this myself, though
>:)
>
>Best regards,
>Alexnder
It's an interisting idea...
I should trust your friend, but I don't bet that conflicts will not ocurr :)
I don't like the idea of be messing around with system tables...
The solution works (let's forget about conflicts that he swears does not
occurr), but to make the exceptions user friendly one should put all the
consistency logic in stored procs and triggers. I like the idea of have a
constraints declared in the tables (create table statement). When a FK is
declared an internal trigger is created to check this constraint, I don't
like the idea of duplicate it on SP's. I could do the checks on the client
(before send the data) but for the same reason I don't like the idea,
besides, AFAIK the trigger knows (in "some mystic way") about other
transactions data as explained why you can create a trigger to enforce
referential integrity for table that has no common change in the data and
not for table that are changed all the time.
Because I like the idea of having referential constraints declared in the
"create table statement" I live with the bad indexes created by FK's that
references small tables, until those indexes don't bring my system down, I
will wait for the FB feature that allows to disable such indexes.
If the server could send more detailed data about the exceptions, I could
format the exception message on the client side... And leave the
referential logic just on the server and decalred just on table creation time.
Thanks for your answer and your time... I like to see how people handle
such situations... Imagination to try diferent aproachs bring some
interesting ideas...
see you
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004
[Non-text portions of this message have been removed]