Re: Proving an Upgrade is Possible

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 05 Jun 2005 09:46:33 -0400
Message-Id: <0fcbn2-375.ln1_at_pluto.downsfam.net>


mountain man wrote:

> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:8vq8n2-0ek.ln1_at_pluto.downsfam.net...

>> Jan Hidders wrote:

>
>> My goal is to always know completely whether all structure changes to a
>> db are valid.
>>
>> Here is a case of where you can prove an upgrade will fail, or at least
>> you
>> cannot prove it will succeed.  If the WIDGETS table currently has a
>> unique constraint on COL_A, COL_B, and COL_C, we know that an upgrade (or
>> any change to the database) can fail if the new version has the unique
>> constraint only on COL_A and COL_B.  While it may succeed in some cases,
>> it
>> will fail in others.

>
>
> Here it seems as if you are relaxing a constraint.
> I would have thought the relaxation of constraints
> should always be successful, whereas the creation
> of constrainst may be problematic.
>

Ooops, I gave the example in reverse, you are correct.

> Will not the determination of success of failure ultimately also
> resolve to the state of the data (in addition to the schema and
> its constraints, etc)?

Yes, this is what makes it not possible to prove in advance that it will work. You don't want features in the product that are known to be fallible before they even go out the door.

>
> Achieving your stated goal relies upon an assumption
> about the data, that *the_data* will be amenable to
> the structural changes imposed. What if it isn't?
>

Again, the point it is to know it in the dev shop and not commit changes that will not work. The original OP is about hwo to always know whether or not the proposed change will work.

> Only a test-conversion will tell you that. This is
> not to say that "proving the schema upgrade is
> possible" ---- at the schema level alone ---- is
> not a worthwhile step in the upgrade path, as
> in the end you need to know about any failure,
> hopefully in advance.

Not true. In the example above, I showed how you could know before the conversion that it would fail, without going through the conversion.

I am seeking the structure of meta data that would offer this ability in the general case, that the feature set is complete enough to describe any application of arbitrary complexity, and that any feature in a particular case can be known to be possible by analysis before attempting the upgrade operation.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Sun Jun 05 2005 - 15:46:33 CEST

Original text of this message