Re: Pre-processing during build
От | dmp |
---|---|
Тема | Re: Pre-processing during build |
Дата | |
Msg-id | 55819CF9.10205@ttc-cmc.net обсуждение исходный текст |
Ответ на | Re: Pre-processing during build (Christopher BROWN <brown@reflexe.fr>) |
Ответы |
Re: Pre-processing during build
|
Список | pgsql-jdbc |
Christopher BROWN wrote: > The idea, for administrators and client developers, is that you wouldn't need to > change anything, and you wouldn't need to pick a driver version. > > The idea being, that instead of their being different versions of the driver > (for different levels of JDBC compatibility) is that there could be one single > binary. For type safety and to avoid creating source files from template > pre-processing, the binary package could contain one driver implementation for > each implemented JDBC version, each more recent version extending the previous > version. Managing this as a client would obviously be a mess, so my suggestion, > if this approach seemed like an appropriate solution (I'm not pushing for it > either, but I don't maintain the project...) is that "org.postgresql.Driver" > could be reimplemented to delegate to the most recent driver implementation > without changing client code. > > This could be done (in the driver code, not in client code) using an approach > like this (hope the indentation doesn't disappear when sending the e-mail...): > > ~ > ~ Thank you for the clarification. danap danap wrote: > Somehow as someone who manages a generic database access tool I don't like the > sounds of this requirement. Why as a client developer should I have to detect > the appropriate Java Version then somehow figure out the user's requirement > for the Driver class to call in your JDBC? I don't have to do this for any other > database so why for PostgreSQL's JDBC. > > It may be of no concern really, but that is going to require me to change > the coding in my client for instantiating your Driver class, which is the > same for all databases so far, all so that you can change your build process, > which does not appear to be broken. > > How about backup and state the one, two, three pros, and cons for initiating > the change in the build process again. Then highlight what additional work > would be required in the code, etc. to accomplish the new build process. Then > the list could input on the proposal. Maybe that has already taken place and > I missed it? > > danap.
В списке pgsql-jdbc по дате отправления: