| Subject | Re: [Firebird-Architect] Extended field/domain DEFAULT usage |
|---|---|
| Author | Jim Starkey |
| Post date | 2006-01-04T03:37:27Z |
Adriano dos Santos Fernandes wrote:
and data in an order than can be readily restored. It doesn't manage
much of anything, let alone dependencies. Dependency management is the
task of the engine.
problem. BLR expressions in default values, computed fields, validation
expressions, and views all go through the same code in the compiler than
clones an expression tree remapping contexts. If the original BLR is
correct, the cloned expression will be correct. BLR is a computational
superset of SQL, but not a one to one mapping, so intelligent
translation of a SQL expression is necessary. For the simple things
we're talking about, it is trivial. Statistical and existential
expressions are syntactically different, but the semantics can be
mapped. If the mapping isn't correct, of course, it won't work, but
that's a bug.
The original SQL philosophy was "we don't fix it, we don't extend it, we
just implement it" was distinctly pre-Borland. The Borland philosophy
tended to be more like "well, whatever." If they had kept to clean
architecture, the DDL expressions would have gone through the same code
as the DML expressions, which work reasonably well. But that's a big
if. On the other hand, however, it means that unkludging the code is
likely to make it smaller, faster, and more reliable. The DSQL code,
even in Vulcan, needs tons and tons of unkludging.
>Jim Starkey wrote:Gbak? Gbak is a backup and restore utilities -- it serializes metadata
>
>
>
>>>is there anything on the plan/roadmap for an extended usage of the
>>>field/domain DEFAULT usage?
>>>
>>>
>>>
>>>
>AFAIK, the main problem is in GBAK that will need to manage more
>dependencies.
>
>
and data in an order than can be readily restored. It doesn't manage
much of anything, let alone dependencies. Dependency management is the
task of the engine.
>As long as the expression is translated into well form BLR, there is no
>
>>I have no doubt that the SQL theorists will object, but in fact it takes
>>exactly two lines in parse.y to implement what you ask.
>>
>>
>>
>Well, I already changed this in the past.
>It works for basic expressions, but didn't work with expressions that
>have SELECT, for example. Some problem with contexts, IIRC.
>Some other thing need to be changed. :-)
>
>
>
>
problem. BLR expressions in default values, computed fields, validation
expressions, and views all go through the same code in the compiler than
clones an expression tree remapping contexts. If the original BLR is
correct, the cloned expression will be correct. BLR is a computational
superset of SQL, but not a one to one mapping, so intelligent
translation of a SQL expression is necessary. For the simple things
we're talking about, it is trivial. Statistical and existential
expressions are syntactically different, but the semantics can be
mapped. If the mapping isn't correct, of course, it won't work, but
that's a bug.
The original SQL philosophy was "we don't fix it, we don't extend it, we
just implement it" was distinctly pre-Borland. The Borland philosophy
tended to be more like "well, whatever." If they had kept to clean
architecture, the DDL expressions would have gone through the same code
as the DML expressions, which work reasonably well. But that's a big
if. On the other hand, however, it means that unkludging the code is
likely to make it smaller, faster, and more reliable. The DSQL code,
even in Vulcan, needs tons and tons of unkludging.