Subject Re: [Firebird-Architect] Multi-level name space
Author Alexandre Benson Smith
Jim,

Jim Starkey wrote:

>If it were just a question of display, views might be a good solution.
>
>
So the legacy consults will be ok.

>However, do remember that Firebird system tables are active -- insert
>into RDB$RELATIONS and poof! the table appears.
>
Yep

>If the system tables
>were replaced with views, we would have to define triggers for update
>that map into a new set of system tables.
>
I thoght that this is the sollution.

> We would also have to rewrite
>vast quantities of substantially ugly code that handles system table
>updates against a whole new system of system tables.
>
As you know, I know nothing about Firebird code. But that will not be
just a simple name change ?

The new system tables will have at least the same structure as the old
system tables with an aditional field called schema (schema_name,
schema_id or whatever), and longer names.

The view will have trigger that will remap the updates to the new system
tables, and there will be code to make the changes live.

> It's that rewrite
>that I want to avoid. I would rather we spent the effort into
>completing the DDL implementation to support all appropriate
>modifications then deprecate the active system tables than rewriting old
>code.
>
>
>
I Agree with that too.

Does anyone have a list of changes that needs direct system tables
updates that is not available trought DDL ?

Does the remmaping of just those fields (that need direct update) in the
view's triggers be enough ?

>Implementing namespaces with concatenation isn't ideal, but it is low
>overhead, simple, and effective.
>
>
Yes, but sorry, this just look to me as a half backed sollution. I would
call it "extend the relation_name" instead of "implement two level
namespace". :-(

Note that I will be glad if I have your suggestion to extend the
relation name size implemented. But I just trying to help to make it
easier for the future changes that will need to be done that is redefine
the system tables, it's names, schemas, and field sizes.

One day or another there will be the need for such views to maintain
backwards compatibilities.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br