Re: Pre-processing during build

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

private final java.sql.Driver impl;

// constructor
Driver()
{
java.sql.Driver impl = null;
try {
Class.forName("java.sql.SQLType");
impl = new PGDriverV8(); // if the above worked => Java 8
} catch (...) {
}
if (impl == null){
try {
java.sql.Connection.class.getMethod("setSchema")
impl = new PGDriverV7(); // else, if the above worked => Java 7
} catch (...) {
}
if (impl == null){
impl = new PGDriverV6(); // else, fallback to min supported version
}
}

// methods
public Statement createStatement()
{
return impl.createStatement();
}

The above should demonstrate the idea, even if it's incomplete.

--
Christopher

On 17 June 2015 at 17:28, dmp <danap(at)ttc-cmc(dot)net> wrote:

> Christopher BROWN wrote:
>
> Then, merge all JARs into a single JAR. Clients could then refer to the
>> specific driver version they require in code, or use a generic Driver
>> class that
>> (in the constructor) detects the appropriate JDBC version and fixes a
>> "final"
>> int or Enum field, used thereafter in "switch" blocks to call the
>> appropriate
>> driver version, acting as a lightweight proxy when the specific driver
>> version
>> can't be referred to (for backwards compatibility). More adventurous
>> developers
>>
> > ..........................................
>
> 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.
>
> ~
>>
> > ~
> > ~
> > ~
> > ~
>
>> Hope that helps ; hope it's not redundant with regards to messages sent
>> since I
>> started typing away my 2 cents... In any case, I regularly use these
>> techniques
>> in production code with no accidents.
>>
>> --
>> Christopher
>>
>
>