[
https://issues.apache.org/jira/browse/PHOENIX-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15836874#comment-15836874
]
Josh Elser commented on PHOENIX-3616:
-------------------------------------
bq. Phoenix returns the expected driver version, so I think the fix would be
purely in Avatica.
Hrm. Is there a need to differentiate between Phoenix's Thin JDBC driver and
the Avatica JDBC driver? I was thinking that would make sense (and make the
numbers line up between the thick and thin drivers), but maybe not.
I don't have a strong opinion here, mostly stemming from a lack of context
around other systems and what is "normal".
In terms of code, we do have a little bit in Phoenix which I assume is
relevant. From {{phoenix-queryserver-client/**/Driver.java}}
{code}
@Override
protected DriverVersion createDriverVersion() {
return DriverVersion.load(
Driver.class,
"org-apache-phoenix-remote-jdbc.properties",
"Phoenix Remote JDBC Driver",
"unknown version",
"Apache Phoenix",
"unknown version");
}
{code}
> Query Server JDBC driver does not return version numbers for server or driver
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-3616
> URL: https://issues.apache.org/jira/browse/PHOENIX-3616
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.7.0
> Environment: Hortonworks HDP 2.5.3
> Reporter: N Campbell
> Priority: Minor
>
> Using the phoenix-4.7.0.2.5.3.0-37-thin-client JDBC driver unable to detect
> version numbers which would be used to attenuate features to exploit or
> workarounds to apply etc.
> getDriverVersion unknown version
> getDriverName Phoenix Remote JDBC Driver
> getDriverMinorVersion 0
> getDriverMajorVersion 0
> getDatabaseMinorVersion 0
> getDatabaseMajorVersion 0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
