How DDL works.

    I've copied the exact explanation from Charlie Caro as it was written on IB-Architect, so you can have an high view of the steps to handle metadata statements and the importance of the Y-Valve that, after all, decides which subsystem will handle a specific call.

From: Charlie Caro <> 
Date: Fri Jun 30, 2000 10:08am 
Subject: Re: SQL Statement Depandance Mapping

Jim Starkey wrote: 
> 
> DDL is a different story. The real DDL operations are performed 
> by ordinary DML to the system tables. SQL DDL is what is known 
> in the biz as syntactic sugar. 
>

The DSQL component emits BLR for DML statements and something called DYN (dynamic DDL) for DDL statements. DYN is yet another byte encoded language for describing data definition statements.

Jim created the DYN language when our VARs were demanding a way to upgrade their customers databases in the field. The customers' databases were licensed for run-time operation only. The high-level tool, GDEF, which performed DDL operations was unlicensed. So, Jim created a low-level, byte-encoded language which GDEF generated from a high-level, GDEF script. The VARs could then distribute the machine-generated DYN to their clients to modify the underlying metadata. I guess you could call DYN an obfuscated, back door for metadata operations.

Today, the same server-side DSQL parser generates parse trees for both SQL DML and DDL statements. The DDL parse trees are passed to a component which emits DYN. That DYN is immediately passed to the Y-valve entrypoint ISC_DDL which interprets the DYN and performs the actions on the system tables.

So the behavior is as Jim describes but the path is a bit more circuitous than one would expect.

Regards, Charlie

This page was last updated on 2000-09-18 20:19:53