Re: Caching driver on pgFoundry?

Kris Jurka wrote:
> On Wed, 5 Sep 2007, Dave Cramer wrote:
>> If this is the case then I would argue that having caching in the
>> appserver is a great idea for everyone using an appserver it does not
>> help the rest of the world that doesn't use an app server.
>
> This is the consensus I'd like to see built before we spend a lot of
> time on something.  Heikki doesn't believe we should do this at all as
> it is covered by DBCP and app server pools.

To be clear, I think it's nice to have one more statement cache
implementation around, with friendly BSD license. I encourage you to
keep working on it, regardless of how this discussion ends.

But let's not bundle it with the PostgreSQL JDBC driver, it's clearly a
separate component. For applications that already have another
connection pool / statement cache implementation, it would be just extra
baggage. And as a separate project, you can use it with other DBMSs as
well. Or bundle it with an app server :).

Another point of view is to think about the release cycles of the JDBC
driver and the caching wrapper. If a bug is found in the wrapper, and
it's bundled with the JDBC driver, we would have to release a new
version of the bundle, forcing an upgrade of both components even if you
only use one. If we add a new feature to the wrapper, is that going to
be backpatched to say the 8.1 branch? What if you're running 8.1 server
and driver, and you want to take advantage of a new wrapper feature?

The wrapper has enough merit to live a happy and successful life as a
project of its own. I don't care if it's a separate pgfoundry project,
or just a separate CVS directory within jdbc project and separate
builds; the main point is that it should be a separate jar file with a
separate release cycle. If we add a link to the latest version of the
wrapper jar from jdbc.postgresql.org download page, people will find it
regardless of where the development happens.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com