Re: [Xen-devel] [OSSTEST PATCH 5/7] Schema: Support database schema updates

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [OSSTEST PATCH 5/7] Schema: Support database schema 
updates"):
> On Thu, 2015-12-10 at 13:51 +0000, Ian Jackson wrote:
> > See schema/README.schema, introduced in this patch, for the design.
> 
> That is all I have done here. Some of the questions I had might be answered
> in the code.

Fair enough.  I have actually executed this, although obviously not on
any production instances.

> > +Update orders
> > +-------------
> > +
> > +There are three reasonable plans for schema changes:
> 
> You've listed 4, which one is unreasonable then ;-)

Oops, fixed.

> > +      Unfinished (or absent)   in old code
> > +      Ready'                   in new code
> 
> Is this really "Ready-prime" or is that a typo?

Typo.

> The "Unfinished", "Ready", "Needed" etc are the literal strings to be used
> as <status> in the special comment, correct?

Yes.

I see that I used the terms `state' and `status' interchangeably.  I
have changed `state' to `status' (and adjusted grammar) in the docs.

The code still talks about `state' in a slightly confusing way.  I can
fix that if you like.

> Who or what is responsible for cranking the handle on the state machine? I
> _think_ it is going to be the commits which make the corresponding changes
> to the code or introduce the new schema snippet?

Exactly.

> Am I right that it would be unusual to have a literal "Unfinished" in a
> schema/*.sql, but rather they would be implicitly in that state by being
> absent?

You might want to introduce a schema change early in a series as
documentation or for testing purposes.  `Unfinished' updates can be
applied with -fff so you can test parts of the code before the rest
is ready.

> > +Update order for Populate-then-rely
> > +-----------------------------------
> > +
> > +This is for when we want to record new information and then later rely
> > +on it.  There are typically two schema changes: to add the column(s)
> > +(`add') and then to add appropriate constraints (`constraint') to
> > +prevent it being left blank.
> 
> Which of the 4 plans above does this correspond to?
> 
> I have a feeling that this actually encapsulates two schema changes in
> lockstep, which may have independent determination of the plan, from the
> state names it looks like the `add' schema is a "Schema first" change and
> the `constraint' one is either "Code first" or "Explicit conditional".

Yes.  I will explain this.

> > +1. Commit: new schema update `add', in state Preparatory.
> 
> Does "Commit" mean simple push to pretest or does it have to pass through
> push gate too? 

I will clarify this.

> The two instances of "1." are because these can happen in parallel?

No.  I failed to update the numbering.

> > +2. Apply: `add'.
> 
> This is something which automated machinery does I think?

No.  I will clarify this.

> > +3. Wait for all executions of old code to finish.
> 
> this is automated also?

Not really.


> > +5. Apply: `constraint'.
> 
> Does `constraint' go to `Needed' at this point, or does that depend on the
> nature of the change (and therefore whether it is "Code first" or "Explicit
> conditional"?

No, it doesn't.  I will clarify this.


> > +"Push depends on schema update" is not currently implemented.
> > +
> > +"Checks for live old code" means
> 
> These two phrases don't existing in this document.
> 
> I think "Push depends on schema update" was called "Schema first" further
> up?

This is confusing.  I will rewrite it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel