[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Ian Campbell writes ("Re: [OSSTEST PATCH 5/7] Schema: Support database schema 
> 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?


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


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?


> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.