rfc: rdbms - new type system

[Ulf Wiger (AL/EAB)]

ke.han wrote:
>
> In general I would like to see more primitives
> for the most common cases:
> float, coercedFloat, number, integer

I have float, number and integer.

What would be the difference between 
number and coercedFloat? (ok, so further
down, you've explained it.)

> intervals of float, number, integer

I used to have {inclusive, Min, Max} 
and {exclusive, Min, Max}. I thought I'd
drop them in favour of 
{'and',[{'>',Min},{'<',Max}]} and similar.
One can of course choose to let the type
be implicit, at least if both floats and
integers are acceptable.

I decided to drop the interval notation
since there are so many different useful
intervals. Ex:

{typedef, natural, {'and',[integer,{'>=',0}]}}

I welcome suggestions on how to express
it better.

> enums of any specified list

I can add enums. Good idea.

> accept undefined

I'll see if I can't make 'undefined' mean
{'==', undefined} rather than "no type specified".

> the attr is a list of another defined type etc...

That would be {list, {type,T}}


> I would prefer something like:
> 
> {{attr, age, type},
>   {'and', [{'>=', 0},
>            {'=<', 150}]},
>   {'or', undefined}}

Not sure how to parse this...

>
>   or perhaps these examples (changing your syntax even more):
> 
>   {{attr, age,
>   	[{integer, {interval, 0, 150},
> 	undefined]}

Using [T1 .. Tn] as shorthand for 
{'or',[T1..Tn]}? 

I've hesitated because I've thought that 
it makes it easier to make mistakes in the
type expressions. Perhaps I'm wrong...


>    {{attr, time,
>    	[integer,
> 	{undefined, fun() -> erlang:now() end}]}  % if the 
> value is undefined, set the value to be the current time.

I used to have a form of dynamic types, but decided to
drop them for now. I'd like to take a conservative 
stance on this for now. These things could be added
later, I think.

> 0..1 and 0..n relationships are the most common cardinality in 
> mainstream apps.  The app spec may say the cardinality should 
> be 1..1 or 
> 1..n, but the db needs to be able to handle empty lists and undefined 
> relation prior to the app code enforcing these rules.
> 
> I am imagining high-level declarations such as:
> 
> {attr, person,
> 	{record, person}}  % must be a record of type person

My current approach is that you have to 
first specify what think a person record
looks like, by adding a typedef:

{typedef, r_person,
 {tuple, Arity, [{'==',person}|...]}}

I used to have a record type, but dropped it, since
I thought using the tuple type would be acceptable.


> {attr, person,
> 	[{record, person}, 	% must be a record of type person
> 	undefined]} 		% undefined is acceptable	
> 
> {attr, people, {list, person}}  % people is a list of person 
> type and if 
> uninitialized will give an empty list. i.e.
> never undefined

I've had that ambition, but since 'undefined'
is just a default value set when the record is
initialized, this would be better handled by
specifying [] as a default value in the record
definition.

Codd's rules for relational databases state
that there must be a NULL value that is separate
from anylegal value. Erlang doesn't have this,
so 'rdbms' can't really achieve proper handling
of null values.

> Need to be able to set a number type which
> accepts both float and integers.

That would be the 'number' type.


  This is an annoyance when using io_lib and others 
> that expect 
> a float and pass it 1 instead of 1.0.  This causes me to write 
> conversion code in my MVC framework.
> 
> Something like this would work:
> 
> {attr, price, coercedFloat} % ensures that if setting 1 
> instead of 1.0, 
> you always get back 1.0
> vs.
> {attr, price, float} % only accepts float
> 	
> or
> 
> {attr, price, number} %% accepts integers and float but does 
> not coerce; 
>   so you get back exactly what you put in

Ok, but then I'd either have to do type coersion 
on reads and match operations, which would really
slow things down, or coerce types in the type 
checking on writes. Doing passive type checking is
both easier and faster.

> So I see from your example how your defined types.
> How are you defining relations?  Any relation
> integrity constraints?

Yes, they are pretty much modeled after the 
ANSI SQL 92 standard. They haven't changed 
fundamentally since the 1.5 version, and are 
described in jungerl, in rdbms/doc/rdbms.pdf.
I've added some things, but haven't verified 
them yet.

/Ulf W