At 09:06 AM 3/8/01 -0500, Craig Stuntz wrote:

>> -----Original Message-----
>> From: Dalton Calford <dcalford@...>
>
>> I do not think that the metadata compiler should even check for the
>> presence of the remote database during metadata operations. It should
>> do what the developer tells it and let the developer deal
>> with the mess if they screw up.
>
> That's an interesting thought, because the implications are much larger.
>Doing this would mean the statements can't be optimized until runtime (even
>if the "remote" DB were accessible at design time, the index statistics
>might not reflect what will be in the "real" "remote" DB at runtime). And
>(optionally) deferring optimization to runtime might have other
>advantages -- the ability to build statements "on the fly" in a stored proc
>would be useful, for instance.
>

The right way to provide this capability is a separate "data manager"
under the Y valve that understands cross database semantics, and
loops back to the Y valve for data access. It was part of the
grand scheme at Interbase (I) and was known as the "mega-database
manager." The idea was that the mega-datamanager would have a
mega-schema that mapped component databases (designed either statically
to ad hoc at run time) and would provide transparent access to
multiple databases. The main things it has to handle are:

1. Meta-data management
2. Query decomposition
3. Coordinated transaction commit

One of the short term goals of Firebird should be to re-establish
the OSRI architecture, prying apart the Y valve, the remote
data managers, the engine(s), and any other data manages that
popup (like the mega-database manager).

Jim Starkey