[Haskell-cafe] Merge hsql and HDBC -- there can only be one!

[Leonel Fonseca]

On the subject of bridging relational persistence and fucntional
programming I wish to communicate on what I'm working on (Tránsito
Abierto Library) (or Open Transit):

1) Whole objective: To disminish to gap between functional and
relational paradigms.

2) Specific objetive: Illustrate and explore the gap.

3) Narrow focus: I'm using Takusen and Oracle and Haskell (á la GHC).
      And Template Haskell (TH).

4) Hypothesis: There'll be always a gap because you're using distinct
nature beasts, but you
a bit more of convinience would yield great improvements.

4.1) Another thought on this is: A mapping always needs to be
specified between data shapes (types/representations).

5) Findings/Achievements(?):

5.1) Generation of Haskell types and iterator code given the shape of
relational table.
         This is not very useful itself. Because of (4.1), using SQL
is an effective way to: (1) convey such mapping and (2) specify
queries that involve more than one table.

5.2) Given a sql query text, use the facilities on Oracle database to
describe the query.
With such description, use Template Haskell to generate Haskell types
and iterator code. Let us call Geco to this generated code that is
built by means of an AST.

5.3) As 5.2 (spliced Geco) but saving the Geco AST. What for?
       It turns out that later, during program execution you can
regenerate a fresh AST code
      and compare it to Geco AST. If there's a difference it means
your database environment is changed and it is likely that your code
is no longer safe.
       The idea here, your program reacts to the enviroment detecting
if its unsafe to run.

5.4) Takusen covers many database datatypes but not all.

5.5) I was about to automate pl/sql bindings using a inspired Takusen
wrapper found on the enumerator tests directory . It follows scheme
5.2.  But it is uncomplete.

5.6) Takusen is limited to iterators up to 8 fields. By using TH,
easily you can have any number of columns in your query.

5.7) I wrote a serialiser library on the DB side and a deserialiser
library on Haskell side. The idea it's to push *any* pl/sql result
onto a string and recover it on the Haskell side. Needs schemes 5.2
and 5.5 to work. Status: Not working.

6) I believe intelligent schema generation is possible following the
scheme above. What you would get is a whole module that would enforce
constraints (cardinality, restrictions, etc).

7) I haven't try the way Haskell -> DB. Neither the storing of
functional values as it was done before in Persistent Haskell and
others.


Cheers,

-- 

Leonel Fonseca.