Claudio,

A fine summary.

Thanks.

--
Martijn

> > If you cannot change the domain, what is the use of this feature in
> > 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

it

> won't notice and therefore, there's no chance to stop the change.
>
> 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

performance

> and also cure the problems with dates as PK's).
> - 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

because

> there's a FK pointing to it.
>