>>Sean Leyne wrote:

>>> 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.

> "Jim Starkey" <jas@...> wrote:
>
>>Uh, Sean, it's been that way since ...

Dmitry Yemanov wrote:

> InterBase was almost frozen for many years while other databases evolved.
> Why do you tend to ignore this fact?
>

Could we stay to the subject and avoid extraneous references to history,
other databases, each others' characters etc.? Here's the situation as
I see it:

Currently in Firebird, if an object is referenced by other objects, you
can't change the primary object (e.g. field) until you delete or alter
the referencing objects (views, triggers, procedures, etc.) to eliminate
the reference. That is a pain in the ass in most cases, and saves your
ass in a few - uncovering forgotten dependencies that are important to
the application.

What is being proposed is a change to the current behavior. When a
referenced object is changed, any compiled instances of the referencing
objects would be marked as requiring recompilation ad the modification
would succeed. When the referencing objects were invoked, they would
be recompiled and errors caused by the change would be discovered.

In the case of changing a field definition, existing - running -
instances of the object would could continue to run unchanged, and most
of the recompilations of referencing objects would occur without error.
However, if an object were deleted or changed in an incompatible way,
the damage caused would not be discovered until some time later when the
referencing objects failed to compile.

On the other hand, SQL schemas tend to be very interrelated with
procedures referencing views that reference procedures and tables with
triggers that reference other views... At the moment, making a
significant change is a real pain. What was, in 1985, a reasonably
simple thing - splitting a table to create two better normalized tables
and creating a view with the old table name - could easily require
deleting half the views, procedures, constraints, and triggers in a
database.

There's got to be a pony in here somewhere. Lets look for the pony
instead of ...


Regards,


Ann