From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-jdbc(at)postgresql(dot)org, Kris Jurka <books(at)ejurka(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Caching driver on pgFoundry? |
Date: | 2007-09-08 22:50:59 |
Message-ID: | 844D9561-315B-4A90-93AA-F2940BB3C374@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On 8-Sep-07, at 5:38 PM, Oliver Jowett wrote:
> Dave Cramer wrote:
>> On 7-Sep-07, at 9:13 AM, Oliver Jowett wrote:
>>>
>>> What is the implementation advantage of making statement pooling
>>> part of the main driver? There are maintenance issues which count
>>> *against* it being part of the driver so you need to provide a
>>> good reason to include it.
>>>
>> Well, it has to be maintained regardless of where it is. So how
>> does that make any difference ?
>
> Err if it is part of the main driver it needs to be maintained as
> part of the main driver and will follow the main driver's release
> cycle. Others have commented on the same thing. It also increases
> the complexity of the main driver, making it harder for a
> particular person to maintain the whole thing.
>
> I'm going to ask again: What is the implementation advantage of
> making statement pooling part of the main driver?
>
It's simpler, there's about half a dozen classes and one if statement
as opposed to implementing the Connection and Statement interfaces
for 3 versions of jdbc and yet another build system that does the same.
Dave
> -O
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2007-09-08 22:57:33 | Re: Caching driver on pgFoundry? |
Previous Message | Oliver Jowett | 2007-09-08 21:44:49 | Re: Caching driver on pgFoundry? |