Re: [OSSTEST PATCH 5/8] Schema: Support database schema updates

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-12-10 at 18:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [OSSTEST PATCH 5/8] Schema: Support database
> schema updates"):
> > On Thu, 2015-12-10 at 17:12 +0000, Ian Jackson wrote:
> > > +<sequence> is a positive integer, which should be unique.  Updates
> > > are
> > > +applied in order.
> > 
> > Don't these also need to be monotonically increasing over time/commits?
> > 
> > i.e. committing (and applying through all the states) sequence #42 and
> > then
> > later committing #12 would be at best confusing and at worse perhaps
> > produce different results when recreating the db (which, I think, would
> > run
> > #12 first).
> > 
> > So maybe the rule needs to be something about being larger than the
> > largest
> > currently applied patch?
> 
> It does say that updates are applied in order.

Right I was considering an osstest repo with 01 and 03 in it, which is
applied and all up to date, but then someone adds 02 and applies it
(therefore after 03).

> > It's not stated outright, but AIUI the <status> of an update changes in
> > a
> > commit which either adds/edits a schema update, or which adds code
> > which
> > adds compatibility/requirements for a particular schema update. Is that
> > right?
> 
> Yes.  I think it should be clear from the rest of the discussion and
> I'm not sure that adding some more text here would help clarify
> things overall.

I was just checking that I had groked it correctly, no need to change
anything.

> > > +Statuses and rules for push and db update
> > > +-----------------------------------------
> > > +
> > > +  Harmless
> > > +  Preparatory
> > > +     No restrictions
> > > +
> > > +  Unfinished
> > > +  (sql fragment entirely missing is equivalent to Unfinished)
> > > +     Schema update: prevented
> > 
> > In the case of "entirely missing" "prevented" must really mean "there
> > can't
> > possibly be anything to do/prevent"?
> 
> Well, if you say
>    ./mg-schema-update apply this-update-does-not-exist
> it will bomb out.
> 
> And
>    ./mg-schema-update apply-all
> will not invent imaginary schema changes out of thin air so that
> it can apply them.
> 
> So, application of nonexistent schema changes is indeed prevented by
> their nonexistence.

Right, I was just wanting to check that you didn't have some mad scheme in
mind for knowing about things which don't exist.

It occurs to me now that while "update-foo" might not exist in the
osstest.git where ./mg-schema-update is being run, it might exist in
another one and therefore have been applied and be present in the database.

Ian.

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