paulruizendaal wrote:

>Another hmmmm...: wouldn't this go circular?
>
>A SQL request inside the metadata code would call the SQL compiler,
>which would call the metadata code, which would.. etc.
>
>This is currently solved in BLR by using field and relation id's,
>which are part of the ODS for system data: no need to call the
>metadata code when compiling such BLR. Standard DSQL does not support
>use of id's.
>
>

It would be circular if we didn't change the startup scheme. There are
any number of ways to handle the problem:

* Populate core system table in-memory metadata structures during
database attachment from initialized structures
* Special case core system table name resolution in the semantic
analysis phase of the compiler
* Execute SQL ddl statements declaring core system tables during
database attachment

Netfrastructure does the latter for the tiny core subset (system.tables,
system.fields, system.domains, system.indexes, system.foreign_keys).
All other system tables are just ordinary tables. The scheme works
beautifully for extensibility for all but the core tables. The core
system tables can be upgraded in place, but with care. Netfrastructure
hasn't had an incompatible ODS change in about four years. In the
meantime, a dozen major subsystems have been phased in. Layering is
really a very good thing.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376