-
Notifications
You must be signed in to change notification settings - Fork 453
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix src and dest namespace handling in clone table operation #5334
base: 2.1
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -37,20 +37,24 @@ class CloneZookeeper extends ManagerRepo { | |
public CloneZookeeper(CloneInfo cloneInfo, ClientContext context) | ||
throws NamespaceNotFoundException { | ||
this.cloneInfo = cloneInfo; | ||
this.cloneInfo.namespaceId = Namespaces.getNamespaceId(context, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is going to change the serialization, and could cause problems with a 2.1.4 upgrade if there are any ongoing clone operations. That should be noted in the release notes for 2.1.4. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How so? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, are you saying that this may cause pre-2.1.4 Clone fate operations to fail, and that I should still check and set this if it's null in CloneInfo? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure exactly what to expect when the serialization of the fate operation's classes are changed, but if a clonetable operation was serialized with 2.1.3, and then interrupted, and then resumed after upgrading to 2.1.4, the deserialization in order to resume the operation will probably fail in some way. I'm not sure if you need to do anything to check it in the code... maybe just warn users that they should make sure there's no outstanding clone operations before doing an upgrade. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made a change in 3cfb06c to handle the case of pre-2.1.4 fate transactions with a note to remove that handling in the 3.1 merge. |
||
TableNameUtil.qualify(this.cloneInfo.tableName).getFirst()); | ||
if (this.cloneInfo.getNamespaceId() == null) { | ||
// Prior to 2.1.4 the namespaceId was calculated in this | ||
// step and set on the cloneInfo object here. If for some | ||
// reason we are processing a pre-2.1.3 CloneTable operation, | ||
// then we need to continue to set this here as it will be | ||
// null in the deserialized CloneInfo object. | ||
// | ||
// TODO: Remove this check in 3.1 as Fate operations | ||
// need to be cleaned up before a major upgrade. | ||
this.cloneInfo.setNamespaceId(Namespaces.getNamespaceId(context, | ||
TableNameUtil.qualify(this.cloneInfo.getTableName()).getFirst())); | ||
} | ||
} | ||
|
||
@Override | ||
public long isReady(long tid, Manager environment) throws Exception { | ||
long val = 0; | ||
if (!cloneInfo.srcNamespaceId.equals(cloneInfo.namespaceId)) { | ||
val += Utils.reserveNamespace(environment, cloneInfo.namespaceId, tid, false, true, | ||
TableOperation.CLONE); | ||
} | ||
val += | ||
Utils.reserveTable(environment, cloneInfo.tableId, tid, true, false, TableOperation.CLONE); | ||
return val; | ||
return Utils.reserveTable(environment, cloneInfo.getTableId(), tid, true, false, | ||
TableOperation.CLONE); | ||
} | ||
|
||
@Override | ||
|
@@ -59,12 +63,12 @@ public Repo<Manager> call(long tid, Manager environment) throws Exception { | |
try { | ||
// write tableName & tableId to zookeeper | ||
|
||
Utils.checkTableNameDoesNotExist(environment.getContext(), cloneInfo.tableName, | ||
cloneInfo.namespaceId, cloneInfo.tableId, TableOperation.CLONE); | ||
Utils.checkTableNameDoesNotExist(environment.getContext(), cloneInfo.getTableName(), | ||
cloneInfo.getNamespaceId(), cloneInfo.getTableId(), TableOperation.CLONE); | ||
|
||
environment.getTableManager().cloneTable(cloneInfo.srcTableId, cloneInfo.tableId, | ||
cloneInfo.tableName, cloneInfo.namespaceId, cloneInfo.propertiesToSet, | ||
cloneInfo.propertiesToExclude); | ||
environment.getTableManager().cloneTable(cloneInfo.getSrcTableId(), cloneInfo.getTableId(), | ||
cloneInfo.getTableName(), cloneInfo.getNamespaceId(), cloneInfo.getPropertiesToSet(), | ||
cloneInfo.getPropertiesToExclude()); | ||
environment.getContext().clearTableListCache(); | ||
|
||
return new CloneMetadata(cloneInfo); | ||
|
@@ -75,11 +79,8 @@ public Repo<Manager> call(long tid, Manager environment) throws Exception { | |
|
||
@Override | ||
public void undo(long tid, Manager environment) throws Exception { | ||
environment.getTableManager().removeTable(cloneInfo.tableId); | ||
if (!cloneInfo.srcNamespaceId.equals(cloneInfo.namespaceId)) { | ||
Utils.unreserveNamespace(environment, cloneInfo.namespaceId, tid, false); | ||
} | ||
Utils.unreserveTable(environment, cloneInfo.tableId, tid, true); | ||
environment.getTableManager().removeTable(cloneInfo.getTableId()); | ||
Utils.unreserveTable(environment, cloneInfo.getTableId(), tid, true); | ||
environment.getContext().clearTableListCache(); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is right, but I don't know fate well enough. I'd like to hear from @keith-turner about whether this is sufficient for the clone operation:
I don't think we need to reserve the source namespace as well (I think reserving the source table is sufficient), but I'm not 100% certain about that.