Subject | Re: [Firebird-Architect] Multi-level name space |
---|---|
Author | Alexandre Benson Smith |
Post date | 2006-01-13T19:40:16Z |
Jim,
Jim Starkey wrote:
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.
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 ?
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
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 -- insertYep
>into RDB$RELATIONS and poof! the table appears.
>
>If the system tablesI thoght that this is the sollution.
>were replaced with views, we would have to define triggers for update
>that map into a new set of system tables.
>
> We would also have to rewriteAs you know, I know nothing about Firebird code. But that will not be
>vast quantities of substantially ugly code that handles system table
>updates against a whole new system of system tables.
>
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 rewriteI Agree with that too.
>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.
>
>
>
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 lowYes, but sorry, this just look to me as a half backed sollution. I would
>overhead, simple, and effective.
>
>
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