Metacat

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:

1. Select the database to use for metadata storage
2. Valid values are oracle, postgresql, sqlserver
   database=postgresql

1. The JDBC connection string used to connect to the database
   jdbc-connect=jdbc:postgresql://localhost/metacat

1. 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.

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.

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.

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.

Original Bugzilla ID was 1238