Project Documentation

Miscellaneous

Legend

PostgreSQL versions

The generator templates in Torque 3.3 are optimized for
PostgreSQL 7.3 and later.
To use an older version of PostgreSQL, do the following:

In the generator, locate the template
templates/sql/base/postgresql/drop.vm
and replace the line

DROP TABLE $table.Name CASCADE;

by

DROP TABLE $table.Name;

Note

The following sections of this HOWTO were written some time ago
and were targeted at the version of Torque that was coupled with the
Turbine application framework.
Contributions towards updating the information below can be submitted to the
Torque Dev mailing list.

PostgreSQL Howto

Turbine comes with a default User implementation which utilizes some libraries,
and code that are not 100% compatible with
PostgreSQL. This document will explain what you need to get the default
Turbine User Implementation running with PostgreSQL. The user management code is
only a small part of Turbine, and the default implementation is easily
replacable. Rather than following the steps in this document, you can always
create your own User implementation which does not require large object support.

JDBC Driver

First of all, the TurbineUser class which comes with Turbine uses a hashtable
to store data relevant to the user. Any data in this hashtable which does
not map to one of the columns in the visitor table is written to a large
object field in the database. Database actions in the TurbineUserPeer and
BasePeer classes are done through the
Village API.
The village API uses the ResultSetMetaData returned by your JDBC driver to
determine the types of the columns in a SQL result set. Unfortunately,
in PostgreSQL large objects are referenced using an OID column (which is a
pointer to the data), and the metadata in the JDBC driver says that columns
of type OID are java.sql.Types.INTEGER.

There is also a bug in the released versions of the PostgreSQL which causes
problems when reading and writing Timestamps. This is fixed in CVS. So to
run Turbine with PostgreSQL you need to get the latest JDBC driver code from
the PostgreSQL CVS server: :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot
(leave the password blank). Before compiling the driver though, you must apply
a patch so the metadata says that OID columns are java.sql.Types.VARBINARY, not
java.sql.Types.INTEGER. Important: If you need the metadata to report
that OID columns are integers for another application, this patch will break
that app. If you've never heard of an OID before, or you only use OID's
to reference large objects, you don't need to worry about it.

Another problem is solved in the more recent JDBC drivers. The test case
JDBCToXMLSchema fails with the driver packaged with at least PostgreSQL
7.1.3 and maybe others. This problem is fixed in the 7.2dev1.2 version
(build date 2001-11-25).
That and other PostgreSQL JDBC resources can be found here:
http://jdbc.postgresql.org/download.html

Patch

This patch may or may not be necessary. If you are having problems with
the driver, please try it out. You may also wish to try upgrading to a
more recent version of the Postgrest driver and also make sure that you
are using the latest released version of
Village.

After applying that patch, compile the driver, and you should be ready to go.
One more problem though is that all actions involving large objects in
PostgreSQL require transactions. There is code in CVS now which automatically
sets up the transaction if necessary, so make sure you're running the recent
snapshots.