I don't see an issue with this, it seems fine. One caveat though is we
see this as an internal interface and we change it all the time. I
wouldn't want to be pushed into making backwards compatibility
guarantees for IMetaStoreClient. Which means that if you develop a
different implementation of it outside Hive it will likely break on
every upgrade.
I don't understand your example use case. You can run Hive now without
the thrift server, so I'm guessing that's not what you're really trying
to do. Are you just interested in building a more efficient
implementation or do you have another use case in mind?
Alan.
Austin Lee <mailto:austin.t....@gmail.com>
December 14, 2015 at 20:48
Hi,
I would like to propose a change that would make it possible for users to
choose an implementation of IMetaStoreClient via HiveConf, i.e.
hive-site.xml. Currently, in Hive the choice is hard coded to be
SessionHiveMetaStoreClient in org.apache.hadoop.hive.ql.metadata.Hive.
There is no other direct reference to SessionHiveMetaStoreClient other
than
the hard coded class name in Hive.java and the QL component operates only
on the IMetaStoreClient interface so the change would be minimal and it
would be quite similar to how an implementation of RawStore is specified
and loaded in hive-metastore. One use case this change would serve would
be one where a user wishes to use an implementation of this interface
without the dependency on the Thrift server. I would appreciate the
community's input and feedback on this proposal.
Thank you,
Austin
