Re: Declarative constraints in practical terms

"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1140973244.316303.23320_at_i40g2000cwc.googlegroups.com...
> dawn wrote:
> >
> > Even if using a non-declarative programming language, one would
> > typically encode metadata (rules/constraints) so that the metadata
> > doesn't say how, but what.
>
> If that's so, then one is using declarative constraints.
>
> For example, if one is using a SQL engine that is written in
> C, an imperative language, ones constraints are still declarative.
> If one builds a declarative constraint enforcement/validation
> engine on top of one's application, one is using declarative
> constraints.
>
> How powerful or complete the engine is doesn't affect whether
> it's declarative or not. You could write a declarative engine
> whose only test it could make was whether one number was
> less than another number, and it'd still be declarative if a
> constraint looked like "a<b".

A little while ago, Kenneth Downs described an engine he was working on, called something like Andromeda. From his description, it seemed like the engine was sort of a supercharged data dictionary. And it could go back and forth between a declarative form and an imperative form for the same piece of data definition. Maybe I'm remembering this wrong.

Anyway, that seems eminently practical to me.

It seems to me that "CREATE TABLE ..." is imperative. When the imperative is carried out, two things happen. First the table is created. Second, the table's description is included in the metadata.

It's not hard to come up with an engine that will read the metadata, and reconstruct the original create scripts, or something logically equivalent. Received on Sun Feb 26 2006 - 20:13:45 CET