Re: Proving an Upgrade is Possible

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

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)?

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?

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.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software