From: | dmp <danap(at)ttc-cmc(dot)net> |
---|---|
To: | Christopher BROWN <brown(at)reflexe(dot)fr>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Pre-processing during build |
Date: | 2015-06-17 16:14:49 |
Message-ID: | 55819CF9.10205@ttc-cmc.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2015-06-17 16:21:52 | Help Reviewing PR's |
Previous Message | Christopher BROWN | 2015-06-17 15:41:12 | Re: Pre-processing during build |