Subject | Re: [Firebird-Architect] Statement Cache [was: User name SYSDBA] |
---|---|
Author | Jim Starkey |
Post date | 2005-08-31T14:07:30Z |
Leyne, Sean wrote:
check the history, you will find that Rdb/ELN (immediate precursor to
GDS/Galaxy, Interbase, and Firebird) was the first database to allow
unrestricted metadata updates which the database was running
multi-user. Before then, all database systems, Oracle, I believe,
included, did an in-place conversion requiring exclusive access to the
object in question. So it isn't a question of Firebird picking up a
useful Oracle feature but Oracle copying a useful Firebird feature.
Borland did introduce a rather stupid, unnecessary restriction on
alteration of foreign keys that has subsequently been fixed.
And, as I said before, there is no need to mark anything as invalid. A
"select *" may be obsolete after adding a new field to a table, but
executing statements are not the least bit invalid. All that is
necessary to to drop obsolete compiled statements from the cache so the
next "prepare" will force a full recompilation.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Jim,Uh, Sean, it's been that way since the GDS/Galaxy alpha in 1985. If you
>
>
>
>>There is never any need to invalidate compiled statements.
>>
>>
>
>Are you sure about that?
>
>One of the feature which Oracle has that I think would be very
>beneficial to Firebird is the ability to change the definition of any
>object (say a table) via at any time. Instead of verifying that the
>dependent objects are not in use, Oracle proceeds with the change but
>marks each of the active dependent objects as invalid, thus requiring
>the object to be recompile.
>
>This approach would go a long way to simplifying schema maintenance.
>
>As such, the ability to mark on object as invalid would be "a good
>thing".
>
>
>
>
check the history, you will find that Rdb/ELN (immediate precursor to
GDS/Galaxy, Interbase, and Firebird) was the first database to allow
unrestricted metadata updates which the database was running
multi-user. Before then, all database systems, Oracle, I believe,
included, did an in-place conversion requiring exclusive access to the
object in question. So it isn't a question of Firebird picking up a
useful Oracle feature but Oracle copying a useful Firebird feature.
Borland did introduce a rather stupid, unnecessary restriction on
alteration of foreign keys that has subsequently been fixed.
And, as I said before, there is no need to mark anything as invalid. A
"select *" may be obsolete after adding a new field to a table, but
executing statements are not the least bit invalid. All that is
necessary to to drop obsolete compiled statements from the cache so the
next "prepare" will force a full recompilation.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376