Subject | Re: [Firebird-Architect] Can we, can we, can we????... |
---|---|
Author | Nando Dessena |
Post date | 2005-06-13T17:17:36Z |
Ann,
A> How does one allow your important,
A> well-designed, but necessarily long queries to run while killing my
A> badly thought-out full-cross product hack? If the parameter is on the
A> connection, how do you insure that all idiots use the kill-my-query
A> option? If on the database, how do you be sure that we don't fall into
A> the Hitch-hikers Guide trap and kill the query that's 2 seconds from
A> giving us the ultimate question to the ultimate answer?
It looks like the only option that's flexible enough is having the
ability to set a database- or connection-wide optional timeout, and
also the ability to set one (or disable the default one) at statement
prepare time.
But all in all I feel that a way to identify and kill a particular
request would cover all this and more, so why settle for less?
Ciao
--
Nando Dessena
http://www.flamerobin.org
A> How does one allow your important,
A> well-designed, but necessarily long queries to run while killing my
A> badly thought-out full-cross product hack? If the parameter is on the
A> connection, how do you insure that all idiots use the kill-my-query
A> option? If on the database, how do you be sure that we don't fall into
A> the Hitch-hikers Guide trap and kill the query that's 2 seconds from
A> giving us the ultimate question to the ultimate answer?
It looks like the only option that's flexible enough is having the
ability to set a database- or connection-wide optional timeout, and
also the ability to set one (or disable the default one) at statement
prepare time.
But all in all I feel that a way to identify and kill a particular
request would cover all this and more, so why settle for less?
Ciao
--
Nando Dessena
http://www.flamerobin.org