Re: Proving an Upgrade is Possible

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sun, 05 Jun 2005 22:26:22 -0400
Message-Id: <lvocn2-1k6.ln1@pluto.downsfam.net>

mountain man wrote:

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

>> mountain man wrote:

>

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

>
>
> It appears that you are trying to develop a generic process
> whereby the consistency/validity of schema changes can be
> tested at the schema level, before the data is dealt with.
> Essentially, a schematic-change exception check between
> the old and the new and proposed elements of schema change.
>
> Is this correct?

Yes.

>
> The testing with any live data happens at a later stage.
> Is this correct?
>

No, I want this to be included in the analysis of the schema change, so it checks both:

mS(2): the destination schema (or meta-State) Delta-mS: the change in schema (or change in meta-State) Delta-S: Change in state of user data

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Sun Jun 05 2005 - 21:26:22 CDT