Re: Version/Change Management of functions?

Jorge Godoy wrote:

>Kenneth Downs <ken(at)secdat(dot)com> writes:
>
>
>
>>We went for generating all server-side code out of a data dictionary. This
>>makes for a significant change in the way change management is handled.
>>
>>In this scenario change management becomes the analysis of "before" and
>>"after" data dictionaries. If the changes are all valid, build the code.
>>
>>
>
>Ken, could you explain it a bit better? I think this is an interesting idea.
>
>
>
Sure. To start off I'd say I'm one of those "biz rules belong in the
server" guys. My guess is we are on the same page there so we'll take
that as a given.

So anyway, some years ago I joined an existing project and was
eventually promoted to systems architect. Along the way I developed
their change management system from scratch (we had more salary dollars
than tools dollars). The "Aha!" moment came when I realized what may
seem obvious to many, which was that you can never, nohow, noway, never
prove ahead of time that any particular piece of code was not going to
break something. You can't even prove it will do what anybody claims.

I wanted a way to know by analysis, just by looking, that any particular
change to a spec would work. That is, it would do what it was supposed
to do, without stopping other things from doing what they were supposed
to do.

It so happens you can have this if you generate your code out of a spec
that is itself data. The spec has to be comprehensive, it can't just be
columns and tables. You need to be able to specify security and
derivations all in one place, that is the only way to specify all
business rules in a single place.

There are two major things you can do to make sure a spec is workable
before you start generating DDL and triggers.

First, you look for mistakes in the spec itself, such as duplicate
column names in tables, references to non-existent tables, and so forth.

Second, you look for mistakes or impossibilities in the delta-spec, the
changes to the spec. For instance, if column COL1 is char(7) and the
new spec has it listed as INT, you can stop there and tell the person
the change is not valid.

Futhermore, you can then do really cool things like generate a report of
what *would* happen if you did an upgrade, such as the creation of new
tables, changes in formulas for existing columns, new cascades, changes
in definitions of keys (added a delete cascade, removed a delete
cascade), and then give it to the customer to sign. Ha! I love that one :)

What falls out of all of this for free is that once you have that data
dictionary you don't have to code maintenance forms anymore, because a
library file can generate any maintenance from from the dictionary
description of a particular table.

So anyway, that's the tip of the iceberg on that. Once you go to a
dictionary-based generation system, it actually changes a lot of how you
do things, not just change management.