PGConnection vs. Connection
От | Markus Schaber |
---|---|
Тема | PGConnection vs. Connection |
Дата | |
Msg-id | 420CD366.8040603@logi-track.com обсуждение исходный текст |
Ответы |
Re: PGConnection vs. Connection
(Oliver Jowett <oliver@opencloud.com>)
|
Список | pgsql-jdbc |
[Crosspost to psql-jdbc, postgis-devel and alex bodnaru] Dear pgjdbc developers, When backporting toe PostGIS jdbc extension to debian woody (which still uses pgjdbc 7.2), Alex Bodnaru (PostGIS debian packager) stumbled over the fact that the addDataType() methods are carried by the org.postgresql.Connection class instead of the org.postgresql.PGConnection interface in 7.3 and up. An additional minor problem is that addDataType(String) is deprecated in 8.0 and this gives compiler warnings (and has the known class loader related problems). This problem is minor because the old method works as good as ever, and pgjdbc 8.0 provides the autoregistration via driverconfig.properties so we do not strictly need addDataType() calls at all in _most_ environments. We're currently wondering what the best method is for supporting 7.2, the following have come to our mind. - Prodiding a patch that is to be applied manually (rsp. by the debian package build process) when building for 7.2. (this is our "current practice"). - Using some kind of pgjdbc autorecognition and preprocessing (e. G. ant filters or C preprocessor). Because of the disadvantages regarding common Java IDEs (Syntax highlighting, error checking tools etc.) and the more complicated build process, I dislike the idea of introducing a separate preprocessing step in a Java project as small as PostGIS jdbc. But this is only my personal opinion, and you can convince me with appropriate arguments. - Manage two different source trees. - Using reflection. This could allow us per run-time distinction to use o.p.PGConnection.addDataType(Class) when running against pgjdbc 8.0, o.p.PGConnection.addDataType(String) against 7.3/7.4, and o.p.Connection.addDataType(String) against 7.2. This way we could ship a single postgis.jar that runs against all pgjdbc versions. - Using our own copy of PGConnection and Connection sources during our build process. We could then use conn.getClass().getName() or such to distinct which code to call, and encapsulate the actual code in functor objects that get instantiated lazy, so we only load the class that actually fits the real connection implementation (this should avoid classloader trouble). Which approach do you think to be the best one? Another question is whether it is worth the effort to develop any complicated scheme, as only a very few lines of code are actually affected. Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
В списке pgsql-jdbc по дате отправления: