Re: Pre-processing during build - Mailing list pgsql-jdbc
| From | Christopher BROWN |
|---|---|
| Subject | Re: Pre-processing during build |
| Date | |
| Msg-id | CAHL_zcPsuJOswS3NZc4_aOEoQZbN1_b5=dXbxk=jV2GZNrQ-Eg@mail.gmail.com Whole thread Raw |
| In response to | Re: Pre-processing during build (dmp <danap@ttc-cmc.net>) |
| Responses |
Re: Pre-processing during build
(dmp <danap@ttc-cmc.net>)
|
| List | pgsql-jdbc |
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
Christopher
On 17 June 2015 at 17:28, dmp <danap@ttc-cmc.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
pgsql-jdbc by date: