paulruizendaal wrote:

>>It would be circular if we didn't change the startup scheme. There
>>are any number of ways to handle the problem:
>>
>> 1 Populate core system table in-memory metadata structures
>> during database attachment from initialized structures
>> 2 Special case core system table name resolution in the semantic
>> analysis phase of the compiler
>> 3 Execute SQL ddl statements declaring core system tables during
>> database attachment
>>
>>
>
>First I thought that 3 was just a clever way of doing 1, until I
>realised that you probably meant keeping the data in the global
>symbol table of the compiler, and not in the metadata module. Keeping
>a metadata cache in the global symbol table is what my oracle-mode
>module does :^) and that's what Netfrastructure apparently does too.
>

Let me clarify. There isn't really a distinction between symbol table
and metadata module. In fact, there is neither. There are table
objects that the database object keeps track of. The table objects keep
track of their fields, and foreign keys, etc. In Netfrastructure, the
compiler asks the connection object to resolve unqualified table
references. The connection object loops through its namespace stacking
asking the database object if it knows about a schemaname:tablename
pair. The database object either does, doesn't (it keeps track of what
it doesn't understand, too), or goes looking in the database. If it
finds it, it creates a new table object, asks it to populate itself, and
adds the table to the table structure. The Statement object, which
handles, among other things, metadata, can also create a new table
object and hand it off to the database object for further management.
So what happens during initialization is that ordinary "create table"
statements get handled as usual, except for a flag that says we're
initializing, don't allocate data segments, and don't don't write the
metadata back to the database.

>
>

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376