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
