Bug #1238
closedpostgresql JDBC config problem in metacat
0%
Description
I was looking at the configuration information for using postgresql in metacat
and I think that the current JDBC setup in build.properties and build.xml needs
modification for newer versions of postgresql. For newer versions, the JDBC
driver (that comes in a standard package) looks like:
/usr/share/pgsql/pg73jdbc3.jar
where 73 refers to the version and the 3 relates to the java version
(unfortunately, the 3 does not imply jre-1.3). The driver that comes with
metacat will not work with these versions of postgresql. I recommend dropping
this driver from the distribution as it could create more problems than solutions.
The easiest fix for this is to change (in build.xml):
<property name="jdbc" value="lib/jdbc7.1-1.2.jar" />
to
<property name="jdbc" value="${jdbc-base}"/>
and put in build.properties:
- Location of postgresql JDBC driver
#jdbc-base=/usr/share/pgsql/pg73jdbc3.jar
This has the disadvantage of having jdbc-base mean slightly different things for
the different backends.
I also noticed that in build.xml you have jdbc-base in some places and jdbc_base
in others.
Updated by Matt Jones almost 21 years ago
Interestingly, I have a current version of metacat running using the original
jdbc .jar file that is checked into lib. I have tested insert, update, and
delete operations through metacat using this jar without any problems. I have
the follwoing properties set in the build.properties:
- Select the database to use for metadata storage
- Valid values are oracle, postgresql, sqlserver
database=postgresql
- The JDBC connection string used to connect to the database
jdbc-connect=jdbc:postgresql://localhost/metacat
- The base directory for locating JDBC jar files (not needed for postgresql)
jdbc_base=./lib
It still might be a good idea to remove the jar file, but so far I have found it
convenient. The changes you suggest change the meaning of the 'jdbc-base"
property, which for other databases represents the directory in which the jdbc
jar file(s) can be found. If we were to change it, I would want to use the
properties consistently across the databases we support (oracle, postgres, mssql
server).
What did you try that did not work for you? Are you sure you ran postmaster
with -i and enabled tcp/ip access, and had the right jdbc connect string when
testing it? What OS was it failing on? Thanks for the further info.
Updated by David Kaplan almost 21 years ago
What version of postgresql are you running? Generally, the drivers are forward
compatible as far as java is concerned - i.e. they will work with java-1.4 if
they work with 1.1. But I don't think the older driver will work with newer
versions of postgresql. It didn't appear to work for me, but then again I
didn't fuss much. In any case, perhaps the solution would be a new parameter
jdbc-jar that would only be used by postgresql.
Updated by Matt Jones almost 21 years ago
I am running postgresql 7.3, the most recent version for redhat 9 as of two days
ago. From what I can see the old jdbc jar file works fine with the new version
of postgres, but I agree we should look into this. One of the initial reasons
for checking it in was we were trying to make a standalone version of metacat
that had everything needed for it to run. We might have other ways of
accomplishing that now that we are closer to a binary installer capability.
Updated by Matt Jones about 19 years ago
Upgraded the driver to the Postgresql version 8 JDBC driver. Tested against
postgres 7.4 and still seems to work. Marking as fixed for the 1.6 metacat release.