Re: the relational model of data objects *and* program objects

Kenneth Downs wrote:
> There an important point here. If meta-data describes user data,
then
> change management is the application of a delta-meta-data. If your
meta
> data is true meta-data, meaning rows and columns (XML flames to
/dev/null),
> then the delta-meta-data is magically transformed into first-order
logic
> and an easily codable sequence of events. But more importantly, you
can
> validate the destination state, and also validate the delta itself
using
> very simple constraints, often just using unique and referential
> constraints. For instance, you can take a SELECT of column types
before
> and after, and look them up in a table of allowed transformations.
The
> table would show "from char to text" as OK, but would have no row for
"from
> char to int", causing the delta to fail validation with message
"cannot
> convert column foo in table bar from char to int".

I think using relations and relational operators against a system catelog is an extremely powerful idea - this might not be exactly what you had in mind, and there are other options, but it's appealing.

> But you can never do this with human-supplied code. There is
absolutely
> nothing intrinsic in the code that will give the same level of
guarantee
> that you are installing something that will actually work.

Sounds like you're advocating declarations rather than procedural code - if so, I agree. While OO has wrapped and packaged procedural code (for good and ill), what's needed are predicates and functions describing the rules, rather than clumsy operational mechanics (procedural code).

> Change Managements = Upgrades = Installs = Development
>
> They are all the same thing and should be handled by the same tools
and must
> be foolproof. Code is the sore thumb in the picture, it does not
allow
> foolproof change management.
>
> Hence the need to find a way to replace human-generated code in the
db.

Agreed. I like Dijkstra's line: "Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code."

• Eric