refactor: fix getDriverVersion and getDriverName and getJDBCMajor/MinorVersion methods #668
Conversation
Any specific reason for doing so? |
Current coverage is 64.37% (diff: 41.66%)@@ master #668 diff @@
==========================================
Files 163 163
Lines 15142 15140 -2
Methods 0 0
Messages 0 0
Branches 2987 2987
==========================================
+ Hits 9727 9747 +20
+ Misses 4182 4156 -26
- Partials 1233 1237 +4
|
@vlsi, prior to maven conversion the version was returned in this format: 42c2e3b#diff-a82520f846ea7ba590d13a466aeafffeL498 The output of postgresql-9.3-1103.jdbc3.jar is "PostgreSQL 9.3 JDBC3g (build 1103)" I doubt anyone is using that to "parse" the version of the driver, for that there is getDriverMajorVersion() and getDriverMinorVersion() methods. It's a matter of correctness since getDriverVersion() means version. |
given that nobody looks at it, I guess this is fine, on the other hand nobody looks at it ;) |
/** | ||
* Retrieves the name of this JDBC driver. | ||
* | ||
* @return "PostgreSQL JDBC Driver" |
panchenko
Oct 20, 2016
getDriverName() incompatibility has potentially higher impact than getDriverVersion().
getDriverName() incompatibility has potentially higher impact than getDriverVersion().
davecramer
Oct 20, 2016
Member
Good catch. Please revert this change
Good catch. Please revert this change
jorsol
Dec 30, 2016
Author
Member
@panchenko have you find a project that use getDriverName() to implement logic and cause a potentially higher impact? I don't have found any.
@panchenko have you find a project that use getDriverName() to implement logic and cause a potentially higher impact? I don't have found any.
IMO general applications use getDriverVersion() and getDriverName() for printing information not for implement logic. I did a quick find (nothing deep) on "potential" projects that "probably" use this information which are mostly ORMs, on JOOQ, Sprint-JDBC, Hibernate and found.... nothing. Since we have entered in a highly speculative area I will close this PR. |
Now that we have moving forward with versioning 42 this can be reconsidered. |
0cbbb4c
to
b7e7fec
/** | ||
* Retrieves the major JDBC version number for this driver. | ||
* | ||
* @return JDBC version major number |
vlsi
Dec 30, 2016
Member
Any clue
Any clue
In general looks good, except two things:
|
* | ||
* @return JDBC version major number | ||
*/ | ||
@Override |
vlsi
Dec 30, 2016
Member
Any clue why do you copy javadocs for @Override
methods?
AFAIK, javadoc build does handle that just fine.
See http://static.javadoc.io/org.postgresql/postgresql/9.4.1212.jre7/org/postgresql/Driver.html#getParentLogger() as an example.
So I would remove all the inherited copy-pasted javadocs unless they have some postgresql specifics.
For instance, connect
method does have some PG specific, so it is LGTM. On the other hand, things like Retrieves the major JDBC version number for this driver
add little value and can be inherited.
However, in this particular method adding some pgjdbc-specific example would help a lot. For instance "The method returns the driver major version, not the versions of the backend. This method would return something like 42 ad pgjdbc versions are like 42.x.y."
Any clue why do you copy javadocs for @Override
methods?
AFAIK, javadoc build does handle that just fine.
See http://static.javadoc.io/org.postgresql/postgresql/9.4.1212.jre7/org/postgresql/Driver.html#getParentLogger() as an example.
So I would remove all the inherited copy-pasted javadocs unless they have some postgresql specifics.
For instance, connect
method does have some PG specific, so it is LGTM. On the other hand, things like Retrieves the major JDBC version number for this driver
add little value and can be inherited.
However, in this particular method adding some pgjdbc-specific example would help a lot. For instance "The method returns the driver major version, not the versions of the backend. This method would return something like 42 ad pgjdbc versions are like 42.x.y."
jorsol
Dec 30, 2016
Author
Member
Good point, I will look at it.
Good point, I will look at it.
vlsi
Dec 30, 2016
•
Member
Well, technically speaking, there's non-trivial build step that unzips jdk sources (e.g. https://github.com/pgjdbc/pgjdbc-parent-poms/blob/master/pgjdbc-core-parent/pom.xml#L270-L278) and adds them to javadoc tool, however it does "just work".
Well, technically speaking, there's non-trivial build step that unzips jdk sources (e.g. https://github.com/pgjdbc/pgjdbc-parent-poms/blob/master/pgjdbc-core-parent/pom.xml#L270-L278) and adds them to javadoc tool, however it does "just work".
*/ | ||
@Override | ||
public int getJDBCMajorVersion() { | ||
return Integer.parseInt(JDBCVERSION.split("\\.")[0]); |
vlsi
Dec 30, 2016
Member
Is mvn.project.property.parsedversion.majorversion
better here?
Is mvn.project.property.parsedversion.majorversion
better here?
jorsol
Dec 30, 2016
Author
Member
No, the mvn.project.property.parsedversion.majorversion
is for the driver version, not for the JDBC specification version, so this should return 4 as the major specification version, this is get from mvn.project.property.jdbc.specification.version
and parsed the first number.
No, the mvn.project.property.parsedversion.majorversion
is for the driver version, not for the JDBC specification version, so this should return 4 as the major specification version, this is get from mvn.project.property.jdbc.specification.version
and parsed the first number.
*/ | ||
@Override | ||
public int getJDBCMinorVersion() { | ||
return Integer.parseInt(JDBCVERSION.split("\\.")[1]); |
vlsi
Dec 30, 2016
Member
Is mvn.project.property.parsedversion.minorversion
better here
Is mvn.project.property.parsedversion.minorversion
better here
jorsol
Dec 30, 2016
Author
Member
No, the mvn.project.property.parsedversion.minorversion
is for the driver version, not for the JDBC specification version, so this should return 0 for Java 6, 1 for Java 7 and 2 for Java 8 as the major specification version, this is get from mvn.project.property.jdbc.specification.version
and parsed the second number.
No, the mvn.project.property.parsedversion.minorversion
is for the driver version, not for the JDBC specification version, so this should return 0 for Java 6, 1 for Java 7 and 2 for Java 8 as the major specification version, this is get from mvn.project.property.jdbc.specification.version
and parsed the second number.
0e8f448
to
415b3c3
@vlsi, requested changes done, removed javadoc that can be inherited, I could not reproduce the behavior using For the second point, the other form to split the version is with a StringTokenizer, but the JavaDocs say:
Happy New Year! |
6f92d48
to
18bedad
Another comment about this? |
@vlsi , is there any other request on this? |
* | ||
* @exception SQLException if a database access error occurs | ||
* @return "PostgreSQL" | ||
* @throws SQLException if a database access error occurs |
panchenko
Jan 12, 2017
I would rather remove "throws" from code, rather then documenting it.
I would rather remove "throws" from code, rather then documenting it.
@@ -281,7 +282,7 @@ | |||
/** | |||
* The application name (require server version >= 9.0) | |||
*/ | |||
APPLICATION_NAME("ApplicationName", null, "name of the application (backend >= 9.0)"), | |||
APPLICATION_NAME("ApplicationName", DriverInfo.DRIVER_NAME, "Name of the Application (backend >= 9.0)"), |
panchenko
Jan 12, 2017
Is this default absolutely necessary?
Is this default absolutely necessary?
jorsol
Jan 12, 2017
Author
Member
And why not?
And why not?
panchenko
Jan 12, 2017
Theoretically, one might want a connection without this property. I don't have a real world example for that, just being cautious about unnecessary changes :-)
Theoretically, one might want a connection without this property. I don't have a real world example for that, just being cautious about unnecessary changes :-)
|
||
public static final String JDBC_VERSION = "/*$mvn.project.property.jdbc.specification.version$*/"; | ||
public static final int JDBC_MAJOR_VERSION = Integer.parseInt(JDBC_VERSION.split("\\.")[0]); | ||
public static final int JDBC_MINOR_VERSION = Integer.parseInt(JDBC_VERSION.split("\\.")[1]); |
panchenko
Jan 12, 2017
in poms there is also jdbc.specification.version.nodot
- might be use it and int math operations instead?
in poms there is also jdbc.specification.version.nodot
- might be use it and int math operations instead?
jorsol
Jan 12, 2017
Author
Member
Maybe, but the problem with the split is?
Maybe, but the problem with the split is?
panchenko
Jan 12, 2017
Less operations during runtime, it will be just a compile time constant.
Less operations during runtime, it will be just a compile time constant.
vlsi
Jan 12, 2017
Member
static final
fields are initialized once, so there's no point in discussing "runtime overhead"
- My main concern on
.split
was it is hard to get right ("off by one" errors and so on).
static final
fields are initialized once, so there's no point in discussing "runtime overhead"- My main concern on
.split
was it is hard to get right ("off by one" errors and so on).
jorsol
Jan 12, 2017
Author
Member
The property is set by default on the pom, so it should be hard to "break" or get the "off by one" errors, I can use the int math if you wish, at least it will allow to catch bad values at compile time.
To be completely safe there must be the properties in the pom.xml and use those values.
jdbc.specification.majorversion
jdbc.specification.minorversion
The property is set by default on the pom, so it should be hard to "break" or get the "off by one" errors, I can use the int math if you wish, at least it will allow to catch bad values at compile time.
To be completely safe there must be the properties in the pom.xml and use those values.
jdbc.specification.majorversion
jdbc.specification.minorversion
e5aeb90
to
7501977
Now is using the int math, what do you think? |
The method was removed in pgjdbc#668, however certain applications might still depend on it. Mark the method as deprecated.
…#905) The method was removed in #668, however certain applications might still depend on it. See https://www.postgresql.org/message-id/CAJFwRrOkE2HsU8FitvEEb971d6XQRfSQJVi1AEsjBxziFGinvQ%40mail.gmail.com Mark the method as deprecated.
…pgjdbc#905) The method was removed in pgjdbc#668, however certain applications might still depend on it. See https://www.postgresql.org/message-id/CAJFwRrOkE2HsU8FitvEEb971d6XQRfSQJVi1AEsjBxziFGinvQ%40mail.gmail.com Mark the method as deprecated.
It turns out ActiveMQ was relying on the original name, so this change broke compatibility. See this issue: https://issues.apache.org/jira/browse/AMQ-6780 |
@hmatt1 not sure how that is our problem ? |
@davecramer it's not, no action needed on your part. I figured I share because jorsol commented
and it turns out ActiveMQ is relying on |
Yes, and it's ActiveMQ fault to relying on getDriverName(), for instance if I want to use pgjdbc-ng or a custom fork of PgJDBC, it makes impossible to change it. |
The driver name is "PostgreSQL JDBC Driver"
The output of the driver version should not include "PostgreSQL"