Vtctl: Adding VExec and Workflow commands#6410
Conversation
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
sougou
left a comment
sougou
left a comment
There was a problem hiding this comment.
I've only eyeballed it. Approach looks good for now. I'll do a deeper dive later.
sougou
left a comment
sougou
left a comment
There was a problem hiding this comment.
One idea I had was to actually have the tablet's VReplicationExec always add the dbname constraint to all the statements. In the case of inserts, it should add the field.
If the constraint is already present, it should verify. This should simplify the vexec code as well as make VReplicationExec more robust.
…onal Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Actually vexec is anyway adding the workflow constraint, so currently dbname is being checked/added at the same time as workflow. So as far as I can see the vexec code will not be simplified. Some of this code will have to be repeated in VReplicationExec if dbname is handled there. Not sure I understand why checking in VReplicationExec makes it more robust: the tablets are anyway chosen by getting the shard masters and we then use the dbname from the provided tabletInfo. I have missed verifying that any user-specified where constraints match the provided workflow/keyspace. Will add. |
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
rohit-nayak-ps
changed the title
As discussed we will be adding the dbname constraint to VReplicationExec as a followup PR. VExec/Workflow will retain current implementation where they add the dbname constraint. |
sougou
left a comment
sougou
left a comment
There was a problem hiding this comment.
Nice work. Some quesitions.
go/vt/wrangler/vexec_plan.go
Outdated
| return newWhere | ||
| } | ||
|
|
||
| func (vx *vexec) buildInsertPlan(ins *sqlparser.Insert) (*vexecPlan, error) { |
There was a problem hiding this comment.
This is something we have to watch, and may have to remove. I can't think of a use case where this will make sense yet. Commands like Reshard etc. are better abstractions in some sense.
There was a problem hiding this comment.
I removed this.
I had not implemented it at first, but we decided to add this for completeness. But yes, it looks pretty useless atm: we can implement any special workflows when we see a need.
…ted in review Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>
3 participants
No description provided.