[
https://issues.apache.org/jira/browse/HIVE-16642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007963#comment-16007963
]
anishek commented on HIVE-16642:
--------------------------------
* Wondering why the ReplicationV1BackwardCompatChecker is in
hcatalog/webhcat/java-client/test, couldnt it be directly itests/hive-unit
* I was thinking a bit more about the test case itself with the
@FixedMethodOrdering. I think calling the assertion method explicitly from each
of the test cases would make it easier to identify which test case containing
events has lead to a failure. I think there might be a way to achieve this
using similar code as below example. Do let me know what do you think?
{code}
public class SampleTest {
static class VerificationRule implements TestRule {
static int a = 0;
@Override
public Statement apply(Statement base, Description description) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
base.evaluate();
a += 1;
assertTrue(a % 2 == 0);
}
};
}
}
@Rule
public VerificationRule rule = new VerificationRule();
@Test
public void test1() {
assertTrue(true);
}
@Test
public void test2() {
assertTrue(true);
}
}
{code}
> New Events created as part of replv2 potentially break replv1
> -------------------------------------------------------------
>
> Key: HIVE-16642
> URL: https://issues.apache.org/jira/browse/HIVE-16642
> Project: Hive
> Issue Type: Sub-task
> Components: repl
> Reporter: Sushanth Sowmyan
> Assignee: Sushanth Sowmyan
> Attachments: HIVE-16642.1.patch
>
>
> We have a couple of new events introduced, such as
> \{CREATE,DROP\}\{INDEX,FUNCTION\} since the introduction of replv1, but those
> which do not have a replv1 ReplicationTask associated with them.
> Thus, for users like Falcon, we potentially wind up throwing a
> IllegalStateException if replv1 based HiveDR is running on a cluster with
> these updated events.
> Thus, we should be more graceful when encountering them, returning a
> NoopReplicationTask equivalent that they can make use of, or ignore, for such
> newer events.
> In addition, we should add additional test cases so that we track whether or
> not the creation of these events leads to any backward incompatibility we
> introduce. To this end, if any of the events should change so that we
> introduce a backward incompatibility, we should have these tests fail, and
> alert us to that possibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
