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

Kris Jurka wrote:
>
> 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.
>

While this is technically true, it is only true to the extent that you
like the default values of all the parameters.  If you need other than
the default values.  As we have more parameters there will be more
parameters that the default value will not be ideal and I would like to
change it, thus the url will get longer and longer.

Take for example the postgresql.conf file.  There are a lot of
parameters in it, and in general there aren't many that I end up
changing on my development machine.  However on my production box where
performance is much more important there are a lot of parameters that I
don't feel the default values are the best.  Likewise I see that once
the driver has a lot of parameters that can tweak a bunch of things in
little ways, you will want to use many of them to get optimal
performance/behavior in your production deployments.


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

But in a lot of cases I am dealing with an application for which I don't
have the source code (or dealing with the source code is a pain), and
the application only exposes the ability to give it a jdbc url.  So you
don't have the option to use the underlying ability of the jdbc api to
use a properties object since the application doesn't expose that
capability.  In fact I don't know of any application the exposes
anything other than the url as being settable by the user.

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

I have experienced a need for most of these at one point or another.
And I forsee the need will only get more pronounced as more options are
exposed as being settable.  For example I would like to see the
logging/debugging capabilities be much more robust (i.e. turn on
statement logging, bind variable logging, and a host of other
possibilities that are usefull when developing or supporting a customer
who has deployed an application), but I have been reluctant to even
think about adding all these different properties until some mechanism
exists to deal with them all other than the url.

I was only suggesting these five ways because a) they are all the
possible ways I could think of, and b) I could see some usefullness for
each.

1) jvm parameters (i.e. -Dxxx=yyy)
   - The use case here is purly hypothetical and probably not at all
realistic, however maybe someone else has some other reason so I
included it in my list.  My use case was: you have an application that
you have deployed that bundles the database with it, so you don't even
have access to setting the url since it is all a black box.  However you
want to turn on logging or something else to diagnose a problem.

2) URL
   - Doesn't need any explaination.

3) property file specified by a url parameter
   - Too many properties to specify on the URL and the URL is the only
mechanism exposed by the application to the end user.  Also allows some
reuse of property settings.  I also like the suggestion someone had of
using JNDI for this as well.

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)
   - useful for development and testing, since you can have a central
place to turn on debugging for example that will get used by all
tests/environments so you don't need to enable it in multiple places.

I am not saying that all of these are good or even that useful, but just
want to throw out some ideas to spark conversation.  None of this has to
be done, but I think it would be useful in some form.  I have started
implementing this more than once, but never got it completed, partly
because of not having a clear idea of what (if anything) others would
want/need from such a feature.

Since you brought up the topic of adding additional parameters, this
seemed like a related topic that would also be useful to get peoples
ideas on.

thanks,
--Barry