You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Curtis Boyden <cb...@pentaho.com> on 2011/04/28 20:25:13 UTC

Hive's JDBC Driver version

Hello Hive People!

               I need to know what version of the Hive JDBC Driver I am working with so that I know what to expect back for column names when I execute a Select statement. For example in 0.5.0 "SELECT account_id FROM account" yields the column name "_col0" whereas in 0.6.0 the same query returns the column name "account_id".

               My question regards the correct way to store the driver version information. I see in HiveDatabaseMetaData I see that getVersion() fetches a full string from the manifest file while getDriverMajorVersion() and getDriverMinorVersion() return a local, static 0. The HiveDriver also provides Driver version information through its methods getMajorVersion() and getMinorVersion() and they both return static int 0 that are scoped to the class.

               I am primarily interested in the HiveDriver.get...Version() methods as I do not want to create a DB connection first to check the DatabaseMetaData, and my first thought is to update the MAJOR_VERSION/MINOR_VERSION values accordingly. Next I was going to change the ..._VERSION static int values to be package visible and use them in HiveDatabaseMeta's getDriverMajorVersion()/getDriverMinorVersion().
               The cost is that someone must manually update the static int values on HiveDriver for each version revision.

               So I was wondering if it would be preferred that all version information is pulled from the manifest file, or if I should move forward with my usage of the HiveDriver static final ints.

               If the manifest version is to be used, should we create two new fields for Major Version / Minor Version or parse the already existing "Implementation-Version".


               Thank you for your direction,
               -Curtis

Re: Hive's JDBC Driver version

Posted by Bill Graham <bi...@gmail.com>.
+1 on pulling all version info from the manifest.

That was generally seen as the best approach when getVersion was
implemented. See https://issues.apache.org/jira/browse/HIVE-760 for
the discussion. This makes it easier to automatically inject versions
at build/release time.


On Thu, Apr 28, 2011 at 11:25 AM, Curtis Boyden <cb...@pentaho.com> wrote:
> Hello Hive People!
>
>               I need to know what version of the Hive JDBC Driver I am working with so that I know what to expect back for column names when I execute a Select statement. For example in 0.5.0 "SELECT account_id FROM account" yields the column name "_col0" whereas in 0.6.0 the same query returns the column name "account_id".
>
>               My question regards the correct way to store the driver version information. I see in HiveDatabaseMetaData I see that getVersion() fetches a full string from the manifest file while getDriverMajorVersion() and getDriverMinorVersion() return a local, static 0. The HiveDriver also provides Driver version information through its methods getMajorVersion() and getMinorVersion() and they both return static int 0 that are scoped to the class.
>
>               I am primarily interested in the HiveDriver.get...Version() methods as I do not want to create a DB connection first to check the DatabaseMetaData, and my first thought is to update the MAJOR_VERSION/MINOR_VERSION values accordingly. Next I was going to change the ..._VERSION static int values to be package visible and use them in HiveDatabaseMeta's getDriverMajorVersion()/getDriverMinorVersion().
>               The cost is that someone must manually update the static int values on HiveDriver for each version revision.
>
>               So I was wondering if it would be preferred that all version information is pulled from the manifest file, or if I should move forward with my usage of the HiveDriver static final ints.
>
>               If the manifest version is to be used, should we create two new fields for Major Version / Minor Version or parse the already existing "Implementation-Version".
>
>
>               Thank you for your direction,
>               -Curtis
>