hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "anishek (JIRA)" <>
Subject [jira] [Commented] (HIVE-16727) REPL DUMP for insert event should't fail if the table is already dropped.
Date Fri, 26 May 2017 09:17:04 GMT


anishek commented on HIVE-16727:

[~sankarh] You are correct in that there is common code for partitioned and unpartitioned
code but that can may be abstracted out as a common code, its just that the test becomes difficult
to read, And the idea of having two test cases as incrementalInsertDropPartitionTable and
incrementalInsertDropUnpartitionTable vs having one method doing both, on failures the test
name will tell you what failed rather than looking at the line in the test where it failed
and trying to figure out which one of them is failing. I just wanted to bring out the point
that readability might be better.

I was just going by the comments on the method get_table_core, as you said there is no difference
in execution path for anyone of them just additional request object setup and as such in get_table_req

> REPL DUMP for insert event should't fail if the table is already dropped.
> -------------------------------------------------------------------------
>                 Key: HIVE-16727
>                 URL:
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Hive, repl
>    Affects Versions: 2.1.0
>            Reporter: Sankar Hariappan
>            Assignee: Sankar Hariappan
>              Labels: DR, replication
>         Attachments: HIVE-16727.01.patch
> Currently, insert event doesn't log the table object as part of event notification message.
During dump, the table object is obtained from metastore which can be null if the table is
already dropped and hence REPL DUMP fails.
> Steps:
> 1. Bootstrap dump/load with a table.
> 2. Insert into the table.
> 3. Drop the table.
> 4. REPL DUMP (incremental).

This message was sent by Atlassian JIRA

View raw message