Re: Comments on adding more connection URL parameters.
От | Kris Jurka |
---|---|
Тема | Re: Comments on adding more connection URL parameters. |
Дата | |
Msg-id | Pine.LNX.4.33.0402040136460.21910-100000@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: Comments on adding more connection URL parameters. (Barry Lind <blind@xythos.com>) |
Ответы |
Re: Comments on adding more connection URL parameters.
|
Список | 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 по дате отправления: