|Subject||Re: [Firebird-Architect] Feature Request: Domains in SP & Triggers.|
A fine summary.
A fine summary.
> > If you cannot change the domain, what is the use of this feature init
> > the first place? I mean, isn't the use of domains in SPs meant to
> > keep things the same (datatypes) if you change the domain. Heck,
> > this is the use for it in the tables, right?
> I will explain only once more.
> - Currently, a procedure and a table can go out of sync because they can't
> share a domain.
> - Handling domains with full properties for now in procs is no lightweight
> task and not well agreed.
> - Therefore, we resort to BASED ON, that will take the data type only. We
> will use this stripped domain in procedures and triggers.
> Currently, you can change the domain for a table and the procedures using
> won't notice and therefore, there's no chance to stop the change.performance
> With the first implementation, we provide three features:
> - Programmer doesn't have to remember the exact data type to declare
> variables or parameters. Only the "surrogate" domain's name (I used
> "surrogate" because people seem to love surrogate keys, an aberration I've
> always disliked, but I concede they may have some enhancement in
> and also cure the problems with dates as PK's).because
> - Code is self-documented.
> - Maybe your table has 30 fields and only two of them are used in
> procedures. Then, if you attempt to change any of those two fields, the
> engine will raise a red flag.
> To handle automatic cascading of changes, we have to discuss automatic
> recompilation or invalidation, a subject that never has been discussed to
> reach a full solution. So, for now, I'm happy if the engine allows me to
> keep the consistency. Think of it like not being able to change a PK
> there's a FK pointing to it.