Subject | Re: [Firebird-Architect] Feature Request: Domains in SP & Triggers. |
---|---|
Author | Ann W. Harrison |
Post date | 2004-10-07T18:02:16Z |
At 08:12 AM 10/7/2004, Geoff Worboys wrote:
from name to id is stored in the system tables.
an instance of a database. Back it up and restore it and you
get another set of ids. That's a good thing. You'll find
that the BLR for procedure uses relation and field names.
System objects that are recreated (e.g. RDB$FORMATS and
RDB$PAGES) use ids.
As for the compilation issue. BLR is an intermediate language
and retains enough context that procedures can be recompiled if
their parameters change. Internal variables are another issue,
but they have no mapping to the RDB$FIELDS (the domain table) so
they're a problem in any event.
Regards,
Ann
>One solution to the problem would be to stop storing objectI guess I don't see how that would help since the translation
>names in compiled code.
from name to id is stored in the system tables.
>Relations have relation_ids, why dontRelation and field ids are designed to be specific only to
>other objects have surrogate identifiers too?
an instance of a database. Back it up and restore it and you
get another set of ids. That's a good thing. You'll find
that the BLR for procedure uses relation and field names.
System objects that are recreated (e.g. RDB$FORMATS and
RDB$PAGES) use ids.
As for the compilation issue. BLR is an intermediate language
and retains enough context that procedures can be recompiled if
their parameters change. Internal variables are another issue,
but they have no mapping to the RDB$FIELDS (the domain table) so
they're a problem in any event.
Regards,
Ann