Re: setQueryTimeout problem !?!?!
От | robert engels |
---|---|
Тема | Re: setQueryTimeout problem !?!?! |
Дата | |
Msg-id | 346482A0-AAB8-40B3-AC9F-841AB04A0A55@ix.netcom.com обсуждение исходный текст |
Ответ на | Re: setQueryTimeout problem !?!?! (Guillaume Cottenceau <gc@mnc.ch>) |
Список | pgsql-jdbc |
The database was not being changed, just the driver. The is fairly standard practice in the java/database world. More recent drivers usually improve compatibility and performance. Oracle, SQL (jtds), and others all work this way. On Mar 18, 2008, at 8:44 AM, Guillaume Cottenceau wrote: > Dave Cramer <pg 'at' fastcrypt.com> writes: > >>> See previous discussion that prompted this change at http:// >>> archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php >> >> Unfortunately the argument assumes that our users are developing new >> applications, not using the driver in an existing application. I >> think >> this change should be reversed. A considerable number of people will >> not be in a position to use an old driver with newer servers just to >> avoid this. > > That's really a matter of practice - how much do you afford to > break in order to fix previous problems or add features. Here, > the story is to fix an unexpected behaviour of the JDBC driver > (setQueryTimeout silently did nothing; it's *bad* to accept a > query timeout value but then not implement any timeout; a > correctly designed application will legally assume that the > queries will timeout after the configured amount of time, which > is not the case). > > Last year, we have upgraded from a 7.4 server to a 8.2 server. I > can tell you that it's quite incorrect to assume that the > application, running fine on 7.4, would magically run fine on 8.2 > too - actually, quite a lot of SQL queries were "broken", because > of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT > on different tables. We've had to validate our application again, > and I think it's normal. > > That is to say, when the database is migrated from major > releases, the application (or the DB layer) sometimes needs > slight modifications, and it would be unreasonable deployment > practices to not validate the application again anyway. > > -- > Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent > Company > Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 > 50 36 > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
В списке pgsql-jdbc по дате отправления: