Re: Comments on adding more connection URL parameters. - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: Comments on adding more connection URL parameters.
Date
Msg-id Pine.LNX.4.33.0402040136460.21910-100000@leary.csoft.net
Whole thread Raw
In response to Re: Comments on adding more connection URL parameters.  (Barry Lind <blind@xythos.com>)
Responses Re: Comments on adding more connection URL parameters.  (Barry Lind <blind@xythos.com>)
List pgsql-jdbc

On Tue, 3 Feb 2004, Barry Lind wrote:

> Kris,
>
> I have no problem with having a larger number of parameters, although we
> should look carefully at how many we add.  So for me the issue isn't how
> many or what types, but how are they set.
>
> I think the process of setting them via the jdbc url is only suitable
> for a limited number of parameters, since urls are often typed in by
> hand into many applications you can't have 50 parameters also needed on
> the url.

No parameters are needed, they are all optional.  So I don't really by
this argument.

> So I beleive that there needs to be some sort of hierarchy of locations
> where parameter values can be set.  I would suggest something like the
> following:
>
> 1) jvm parameters (i.e. -Dxxx=yyy)
> 2) URL
> 3) property file specified by a url parameter
> 4) property file bundled in the jar (i.e.
> org/postgresql/conf.properties) - this allows application builders who
> bundle the jdbc driver with their application to set the parameters
> their application requires
> 5) property file in a default location (like user.home)
>
> Once the number of parameters becomes larger, I would expect most people
> will end up using property files for their parameters and then change
> individual ones on a case by case basis via the url or jvm for exception
> cases.

I suspect people with large numbers of properties will use a properties
file, but we don't want to deal with files.  As Oliver mentioned there is
a DriverManager.getConnection method that takes a properties object so it
should be the user's responsibility to construct this from whatever
sources they desire.

The only idea I found interesting was "4) property file bundled in the
jar"  This could potentially make deploying a number of applications that
behave in the same way simpler, but would also I imagine generate a number
of questions like "Why is the driver doing ..." not knowing that the jar
file had these configuration parameters.  All of these ideas are something
I've never heard people ask for, so I'd like to know we are solving a
general problem before introducing this complexity and potential for
errors.

Kris Jurka



pgsql-jdbc by date:

Previous
From: Oliver Jowett
Date:
Subject: Re: Comments on adding more connection URL parameters.
Next
From: Kris Jurka
Date:
Subject: Re: Comments on adding more connection URL parameters.