[ 
https://issues.apache.org/jira/browse/BEAM-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Robertson updated BEAM-4260:
--------------------------------
    Description: 
The {{HCatalogIO}} does not work with environments providing Hive Server 1.x 
which is in widespread use - as an example the latest Cloudera (5.14.2) 
provides 1.1.0.
 
The {{HCatalogIO}} marks it's Hive dependencies as provided, so I believe the 
intention was to be open to multiple versions.
 
The issues come from the following:  
 - use of {{HCatUtil.getHiveMetastoreClient(hiveConf)}} while previous versions 
used the [now 
deprecated|https://github.com/apache/hive/blob/master/hcatalog/core/src/main/java/org/apache/hive/hcatalog/common/HCatUtil.java#L586]
 {{getHiveClient(HiveConf hiveConf)}}  
 - Changes to the signature of {{RetryingMetaStoreClient.getProxy(...)}
 
Given this doesn't work in a major Hadoop distro, and will not until the next 
CDH release later in 2018 (i.e. widespread adoption only expected in 2019) I 
think it would be worthwhile providing a fix/workaround.

I _think_ building for 2.3 and relocating in your own app might be a workaround 
although I'm still testing it.  If that is successful I'd propose adding it to 
the project README or in a separate markdown file linked from the README.

Does that sound like a reasonable approach please?

  was:
The {{HCatalogIO}} does not work with environments providing Hive Server 1.x 
which is in widespread use - as an example the latest Cloudera (5.14.2) 
provides 1.1.0.
 
The {{HCatalogIO}} marks it's Hive dependencies as provided, so I believe the 
intention was to be open to multiple versions.
 
The issues come from the following:  
 - use of {{HCatUtil.getHiveMetastoreClient(hiveConf)}} while previous versions 
used the [now 
deprecated|https://github.com/apache/hive/blob/master/hcatalog/core/src/main/java/org/apache/hive/hcatalog/common/HCatUtil.java#L586]
 {{getHiveClient(HiveConf hiveConf)}}  
 - Changes to the signature of {{RetryingMetaStoreClient.getProxy(...)}
 
Given this doesn't work in a major Hadoop distro, and will not until the next 
CDH release later in 2018 (i.e. widespread adoption only expected in 2019) I 
think it would be worthwhile providing a fix/workaround.

I _think_ building for 2.3 and relocating might be a workaround although I'm 
still testing it.  If that is successful I'd propose adding it to the project 
README or in a separate markdown file linked from the README.

Does that sound like a reasonable approach please?


> Document usage for hcatalog 1.1.0
> ---------------------------------
>
>                 Key: BEAM-4260
>                 URL: https://issues.apache.org/jira/browse/BEAM-4260
>             Project: Beam
>          Issue Type: Improvement
>          Components: io-java-hcatalog
>    Affects Versions: 2.4.0
>            Reporter: Tim Robertson
>            Assignee: Tim Robertson
>            Priority: Minor
>
> The {{HCatalogIO}} does not work with environments providing Hive Server 1.x 
> which is in widespread use - as an example the latest Cloudera (5.14.2) 
> provides 1.1.0.
>  
> The {{HCatalogIO}} marks it's Hive dependencies as provided, so I believe the 
> intention was to be open to multiple versions.
>  
> The issues come from the following:  
>  - use of {{HCatUtil.getHiveMetastoreClient(hiveConf)}} while previous 
> versions used the [now 
> deprecated|https://github.com/apache/hive/blob/master/hcatalog/core/src/main/java/org/apache/hive/hcatalog/common/HCatUtil.java#L586]
>  {{getHiveClient(HiveConf hiveConf)}}  
>  - Changes to the signature of {{RetryingMetaStoreClient.getProxy(...)}
>  
> Given this doesn't work in a major Hadoop distro, and will not until the next 
> CDH release later in 2018 (i.e. widespread adoption only expected in 2019) I 
> think it would be worthwhile providing a fix/workaround.
> I _think_ building for 2.3 and relocating in your own app might be a 
> workaround although I'm still testing it.  If that is successful I'd propose 
> adding it to the project README or in a separate markdown file linked from 
> the README.
> Does that sound like a reasonable approach please?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to