Re: Proving an Upgrade is Possible

Jan Hidders wrote:

> Kenneth Downs wrote:

>> I would love to be able to determine with certainty if a certain
>> operation
>> can be validated before it is performed.  This is the operation of
>> changing the state of a database by an upgrade.

An upgrade of a database, not the DBMS software. In the trivial case just changes to the tables and columns, but also at very least unique and referential constraints.

The meta-state is all possible states described by the data dictionary (or meta-data if you prefer).

If you have a data dictionary containing the meta data that describes the database, an upgrade = a change to the data dicitonary. So just as a user transaction changes the state of a database, an upgrade changes the meta data, or the meta state.

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.

How would you know in advance though that this upgrade could not work? Well, its simple enough. You have the current state of the database described in tables, meta-State 1, or mS(1). You have the destination state described in other tables, mS(2). You join them together and look at everything that changes, such as key definitions. The dropping of a column in a key is not allowed, so the upgrade log puts out an error and refuses to run.

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