Re: Upgrade as Change in Meta-state

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Thu, 21 Oct 2004 19:57:58 -0400
Message-ID: <7ei9lc.n3s.ln_at_mercury.downsfam.net>


Laconic2 wrote:

>
>>
>> Compare an upgrade to everyday use. In everyday production use, a
> database
>> is going through a series of serializable changes to state, with the
>> unspoken assumption that the meta-state, the description of allowed
> states,
>> is itself unchanged.
>
> The same can be said of a program or a package, can't it?
>

well, sure. Does that come into play?

>>
>> Let us say that an upgrade is a change in meta-state, a change in the
>> description and implementation of allowed states. In English, that would
>> be new tables, columns, and constraints.
>>
>
> The "user of the DBMS" has the right to create new tables, columns and
> constraints.
> We need to define who "the user of the DBMS" is. This is harder than it
> sounds.
>

From a vendor's point of view, selling the EDS, we push that definition off to you. The idea is to make it as powerful as possible, so that you have as much flexibility as possible.
>
> And when your requirements change, you should just update the model,
> "click
> here" and have the diff engine go to work.
> It should spit out all the upgrades needed to the Java, the DML, the DDL,
> and the preexisting data!
>
> In the meantime, what shall we do?

Brush up on our XML skills? (ducking)

>
>>
>> OK, so all biz rules are in data. This means that an upgrade is
>> described
>> by a set of tables that describe the new state. This makes it childishly
>> simple to do the following:
>>
>
> This means that there are "biz meta-rules" doesn't it? Who codes the
> meta-rules?
> If I buy from you, and I want to change the rules, great! But what if I
> want to revise and extend the meta rules?

If you want to change it I'll give you the source code under the GPL, you do whatever you want with it. Paying customers are those who desire the service of an outside vendor or that vendor's established package.

>
> You provided me with a "maximum salary" parameter, and it's childishly
> simple to update that parameter. Great!
> But now the Gubbermint shows up, and tells me that I have to implement a
> "maximum value of stock options" in addition to a maximum salary, and I
> have to do it withing 90 days. I call up the sales person at your
> company,
> who says, "Gee we never thought of that! Wait for the the next release!"
> "When is that?". "Two years form now".
>
> Do you see the problem?
>

Do I see it? The express purpose of this approach is to accept it, embrace it, love it. There is no such thing as the finished product, it will always change, that's why changing it must be easy to do, and easy to manage.

>
>
>> 1) validate the new state
>> 2) validate the state transition prior to upgrading (absolutely crucial)
>> 3) diff the states and generate only the necessary DDL
>> 4) self-document the operation, even possibly estimate time
>>
>
> You've just described a transaction, haven't you? It's atomic,
> consistent,
> isolated and durable, eh?
>

Exactly, yes.

>
> I'm going to start a new thread on "creating the DB-DIFF engine" it's
> more skunk works.
>
>
<big snip>
>
> I'm with Tony on this one. This would never fly at my shop.

(ducking) um, if it would never fly, why are you working on the diff engine?

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me
Received on Fri Oct 22 2004 - 01:57:58 CEST

Original text of this message