vitess.io/vitess@v0.16.2/go/vt/vtctl/workflow/doc.go (about)

     1  /*
     2  Copyright 2021 The Vitess Authors.
     3  
     4  Licensed under the Apache License, Version 2.0 (the "License");
     5  you may not use this file except in compliance with the License.
     6  You may obtain a copy of the License at
     7  
     8  	http://www.apache.org/licenses/LICENSE-2.0
     9  
    10  Unless required by applicable law or agreed to in writing, software
    11  distributed under the License is distributed on an "AS IS" BASIS,
    12  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    13  See the License for the specific language governing permissions and
    14  limitations under the License.
    15  */
    16  
    17  /*
    18  Package workflow defines types and functions for working with Vitess workflows.
    19  
    20  This is still a very rough sketch, far from a final API, but I want to document
    21  some things here as I go:
    22  
    23  (1) The lines between package workflow and package workflow/vexec are, uh,
    24  
    25  	blurry at best, and definitely need serious thinking and refinement. Maybe
    26  	there shouldn't even be two separate packages at all. The reason I have the
    27  	two packages right now is because I'm operating under the assumption that
    28  	there are workflows that are vexec, and then there are other workflows. If
    29  	it's true that all workflows are vexec workflows, then probably one single
    30  	package could make more sense. For now, two packages seems the way to go,
    31  	but like I said, the boundaries are blurry, and things that belong in one
    32  	package are in the other, because I haven't gone back and moved things
    33  	around.
    34  
    35  (2) I'm aiming for this to be a drop-in replacement (more or less) for the
    36  
    37  	function calls in go/vt/wrangler. However, I'd rather define a better
    38  	abstraction if it means having to rewrite even significant portions of the
    39  	existing wrangler code to adapt to it, than make a subpar API in the name of
    40  	backwards compatibility. I'm not sure if that's a tradeoff I'll even need to
    41  	consider in the future, but I'm putting a stake in the ground on which side
    42  	of that tradeoff I intend to fall, should it come to it.
    43  
    44  (3) Eventually we'll need to consider how the online schema migration workflows
    45  
    46  	fit into this. I'm trying to at least be somewhat abstract in the
    47  	vexec / queryplanner APIs to fit with the QueryParams thing that wrangler
    48  	uses, which _should_ work, but who knows?? Time will tell.
    49  */
    50  package workflow