[Ur] Advice on SQL tables needed

[Artyom Shalkhakov]

Hi Adam,

It seems like you misunderstand my misunderstanding. :-)

What I'm struggling with is actually the type-level (kind-level?)
stuff of Ur. The rules given in the manual are consistent and all, but
I don't have the necessary knowledge to understand them ATM (not to
say I don't work towards this).

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?

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.

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.

The tables I'm talking about arise frequently: these tables describe
entitities (one table -- set of entities of the same "sort", or
"class", or even "category"), and all of them have a primary key [id],
the identity (as in logic and philosophy) of entitity. There are of
course many more other "sorts" of tables that I don't want to handle
here.

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.

I guess this finally explains what I want to do and why.

Cheers,
Artyom Shalkhakov.

2010/1/21, Adam Chlipala <adamc at impredicative.com>:
> Artyom Shalkhakov wrote:
>> Having written a bit more of my application, I encountered a pattern
>> which I'd rather abstract away, but don't know how.
>>
>> In my case, there are about four tables, each of which is equipped
>> essentially the same code (namely, CRUD operations). What I'd like is
>> to provide such table to a parameterized module, which would give me
>> the following functions:
>>
>> val create: row' ->  transaction row
>> val read: id ->  transaction (option row)
>> val update: row ->  transaction unit
>> val delete: row ->  transaction unit
>>
>> (here, row' would be the schema of the table without the primary key,
>> whereas row would contain the primary key -- here, the primary key
>> would be a simple auto-incrementing integer)
>>
>> I've studied the samples (orm and crud), but one of them unnecessarily
>> ties UI to the table structure, and another tries to abstract tables
>> away, which I don't want to do.
>>
>
> I would do this with a functor much like that of the Orm1 demo, but
> accepting the table as a value within the functor's input module.
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>