[Ur] Advice on SQL tables needed

[Adam Chlipala]

Artyom Shalkhakov wrote:
> Now, in the manual an SQL table is said to be introduced by a
> type-level function:
>
> con sql_table :: {Type} ->  {{Unit}} ->  Type
>
> (I read it thus: "give me a schema, and I promise to give you a type
> of your table")
>
> The question is: is it possible to get the set of attributes and the
> set of keys given a table?
>    

No.  In general, there is no way to extract the indices of a type.  
Instead, you must pass the indices as separate arguments.  I believe 
this is shown clearly by the Crud demo's functor signature.

> In the orm you mentioned, the facility of defining tables and foreign
> key relationships between them essentially duplicates (part of) that
> of the language (why? is there anything I'm missing?), giving you neat
> functions in exchange.
>    

It was just an example of a nifty thing you can do.  The whole thing 
makes just as much sense when the functor takes a table as a new input.

> What if I already have the tables defined and now I just want a few
> (effectful) frequently needed functions? Then, given a table, it's
> attributes and the primary key, we can do our job.
>    

Crud does exactly this.  Can you explain which new thing you want to do, 
such that it is not demonstrated in Crud?  (The fact that the functions 
are local [not exported in the functor's output signature] and/or the 
fact that they generate web pages is not relevant to the functor's input 
signature.)

> Thinking this way, I write a module with a signature like this:
>
>    
>> functor Entity(M: sig
>>    table t (* the parameter *)
>> end): sig
>>    val create: row' ->  transaction id (* FIXME: how to deduce [row'] and [id] from [t]? *)
>>    (* other functions *)
>> end
>>      
> The table [t] must have a primary key [id: int] (or something, we
> don't want to dictate naming), and other fields we don't really care
> about.
>    

You can't declare a table input without declaring its column types.  
Again, I'm confused about how to respond, since I believe Crud 
demonstrates exactly this pattern, even up to the required presence of 
an id column.