| Subject | Re: [Firebird-Architect] Multi-level name space |
|---|---|
| Author | Alexandre Benson Smith |
| Post date | 2006-01-12T23:45:31Z |
Jim Starkey wrote:
Just a lurker suggestion.
If the developers start to redesign the system tables (maybe part of the
schema implementation). what about if the new system tables be declared
like:
System.Relations
System.Schemas
System.Fields
and so on.
and make views to handle the backward compatibility
create view rdb$Relations(rdb$relation_name, bla, bla, bla) as
select
System.Schemas.Schema_Name || '.' || System.Relations.Relation_Name,
bla, bla, bla
from
System.Schemas join
System.Relations on (System.Schemas.Schema_ID =
System.Relations.Schema_ID)
it would transparently appears to old clients as the suggestion you
provied to the name of the table being "Foo.Bar".
About the default schema, don't know what will be the better choice:
1.) SQL Command to define the current/default schema
2.) Connection Parameter to define the current/default schema
About the question like this:
set default schema to fred
create table Foo
select fred.foo -- ok (fred.foo)
select foo -- ok (fred.foo)
select mary,foo -- error (no such table, no such schema, so such
schema/table)
I reall like backwards compatibility, and think it is extremelly
important, I don't question you about this, but if an upgrade to a new
version requires that the DBA do a back-up/restore cycle, it could set
the default schema too, or even prefix the current tables to the USER
schema by default (or a LEGADE schema or PUBLIC schema or some other
name that indicates that those tables doesn't have an schema define),
and look for tables on this schema as a last resource, don't know what
unexpected behaviours it could bring.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
>Not sufficiently backwards compatible. It would require that everyHi !
>query against system tables be rewritten. It also would allow utilities
>work work against old and new versions. It's the obvious way to handle
>it (sans RDB$, of course) if we were starting over scratch, and also the
>way I handled the issue in Netfrastructure. But the backwards
>compatibility problem should make it a non-starter for Firebird.
>
>
Just a lurker suggestion.
If the developers start to redesign the system tables (maybe part of the
schema implementation). what about if the new system tables be declared
like:
System.Relations
System.Schemas
System.Fields
and so on.
and make views to handle the backward compatibility
create view rdb$Relations(rdb$relation_name, bla, bla, bla) as
select
System.Schemas.Schema_Name || '.' || System.Relations.Relation_Name,
bla, bla, bla
from
System.Schemas join
System.Relations on (System.Schemas.Schema_ID =
System.Relations.Schema_ID)
it would transparently appears to old clients as the suggestion you
provied to the name of the table being "Foo.Bar".
About the default schema, don't know what will be the better choice:
1.) SQL Command to define the current/default schema
2.) Connection Parameter to define the current/default schema
About the question like this:
set default schema to fred
create table Foo
select fred.foo -- ok (fred.foo)
select foo -- ok (fred.foo)
select mary,foo -- error (no such table, no such schema, so such
schema/table)
I reall like backwards compatibility, and think it is extremelly
important, I don't question you about this, but if an upgrade to a new
version requires that the DBA do a back-up/restore cycle, it could set
the default schema too, or even prefix the current tables to the USER
schema by default (or a LEGADE schema or PUBLIC schema or some other
name that indicates that those tables doesn't have an schema define),
and look for tables on this schema as a last resource, don't know what
unexpected behaviours it could bring.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br