-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
migrater: identify shard migration differently #5178
migrater: identify shard migration differently #5178
Conversation
Previously, we identifid a migration as SHARD of the source and target keyspaces matched. But it's possible to have table migrations within a keyspace. This new way identifies a migration as SHARD only if the source and target shards don't match. Signed-off-by: Sugu Sougoumarane <ssougou@gmail.com>
@@ -902,34 +902,6 @@ func TestMigrateNoTableWildcards(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestShardMigrateTargetMatchesSource(t *testing.T) { |
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.
There is no way of testing it?
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.
the test was for the error message, which is no longer being produced.
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 meant in general. The whole test was deleted and nothing was added.
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 remember why I didn't add a test. It's more relevant to add one when we add the shard validation (the TODO that I added). But this change is a pre-req for the other changes I have lined up.
@@ -239,7 +239,16 @@ func (wr *Wrangler) buildMigrater(ctx context.Context, targetKeyspace, workflow | |||
if mi.sourceKeyspace != mi.targetKeyspace { | |||
mi.migrationType = binlogdatapb.MigrationType_TABLES | |||
} else { | |||
// TODO(sougou): for shard migration, validate that source and target combined |
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.
is this in a forthcoming PR? wondering why a TODO rather than implement it in this one.
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.
Yeah. I've added it to the list.
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.
LGTM
Previously, we identifid a migration as SHARD of the source and
target keyspaces matched. But it's possible to have table migrations
within a keyspace.
This new way identifies a migration as SHARD only if the source and
target shards don't match.
Signed-off-by: Sugu Sougoumarane ssougou@gmail.com