[
https://issues.apache.org/jira/browse/HIVE-17983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341373#comment-16341373
]
Vihang Karajgaonkar commented on HIVE-17983:
--------------------------------------------
bq. Also on these scripts I have unrolled them so that scripts no longer invoke
other scripts. For example, the 2.3->3.0 upgrade script now includes all the
create table and alter table statement itself rather than calling run on the
various 0XX-HIVE-XXXXX.rdbms.sql scripts. The main reason for this is that
HiveSchemaTool went to a lot of work to do the unrolling on these scripts.
I think having separate patch scripts which a main upgrade scripts calls is a
cleaner way to apply schema changes. It also helps with the backporting of the
schema changes between branches (less conflicts and chances of errors). If it
is possible we should probably try to maintain that in the standalone-metastore
as well. Looks like sqlline does have {{!script}} and {{!run}} commands to run
scripts. Can we use it for this usecase? [~ngangam] also has worked a lot on
schema upgrade patches and he might have some thoughts as well.
Also, I agree with [~thejas] above and we should provide an upgrade path from
atleast 2.0.0 so that it is easier for users to adopt it. Its not necessary
that all the users will be at 2.3.0 when they want to adopt
standalone-metastore.
bq. how Hive and the standalone metastore should be installed. Do we completely
separate them out and require users to install the standalone metastore and
then Hive? This is easier for devs but harder on ops and packagers. But it also
gives users maximum flexibility. Or do we modify the Hive build process to pull
in the standalone metastore packages and produce a distribution that includes
the metastore? This is more work for us devs. It gives users a seamless
experience between older and newer versions of Hive. It also matches user
expectations (I can't think of any database that requires you to install its
data catalog as a separate package). On the other hand it locksteps a version
of Hive with a version of the metastore, which may not be what people want.
I think second option here is a better alternative considering we want to
maintain backwards compatibility as much as possible and make it easier to
migrate from current metastore to standalone-metastore. Hive is anyways in
lockstep with metastore version and a lot of code in Hive assumes that. I am
not sure we are there yet to have one version of hive talking to another
version of metastore and that should be a separate effort.
> Make the standalone metastore generate tarballs etc.
> ----------------------------------------------------
>
> Key: HIVE-17983
> URL: https://issues.apache.org/jira/browse/HIVE-17983
> Project: Hive
> Issue Type: Sub-task
> Components: Standalone Metastore
> Reporter: Alan Gates
> Assignee: Alan Gates
> Priority: Major
> Labels: pull-request-available
> Attachments: HIVE-17983.2.patch, HIVE-17983.patch
>
>
> In order to be separately installable the standalone metastore needs its own
> tarballs, startup scripts, etc. All of the SQL installation and upgrade
> scripts also need to move from metastore to standalone-metastore.
> I also plan to create Dockerfiles for different database types so that
> developers can test the SQL installation and upgrade scripts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
