[Haskell-cafe] Haskell and Databases
Tobias Schoofs
In particular I am looking at
haskelldb and the Takusen Database.Enumerator library.
In haskelldb, there are very good ideas aiming to represent database objects as (typeable) Haskell objects, instead of embedding SQL in plain strings.
This is really an interesting approach that overcomes the hiatus between the database there and the processing logic here.
Unfortunately, the library cannot deal with some obvious issues related to this concept;
conflicts arise, for instance, when Haskell keywords are used as names of attributes or tables or when the same name is used for an attribute and for a table (which is perfectly legal in SQL).
Also, haskelldb cannot cope with peculiarities of popular database tables, such as ISAM tables - which are case sensitive.
Another, more conceptual issue, is the lack of database cursors.
Database programs, usually, do not just issue isolated SQL statements, but implement a processing logic with nested queries and DML statements. A DB library should provide control structures to ease this kind of processing.
A library that tackles this issue, is the Takusen Database.Enumerator, again, a library with very strong ideas.
Unfortunately, in Takusen there is nothing like the haskelldb DSL.
Concerning, cursors, Takusen uses iterators to stream query results.
This makes a lot of sense.
The iterators, however, cannot be used to implement the nesting of queries.
The user has to provide an additional action which is responsible for all the cursor-related logic.
The tools provided to deal with cursors resemble very much the instructions found in other database-oriented languages, such as PL/SQL.
This leads to verbose code where cursor control is implemented in a quite "imperative" way.
The user, however, should be concerned with getting her queries right, not with the "technical" details of fetching from cursors.
In summary, what I miss is a database library that
- integrates haskelldb approach with
- a "functional-style" cursor concept
Is anybody working on something like this?
Thanks,
Tobias
Yves P----
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Christopher Done
> There is something that bothers me with that text, I can't get to grasp what
> it is...
It's bigger than Godzilla?
Miguel Mitrofanov
> <398E692F.asc>
Greg Weber
Tobias Schoofs
Thanks,
Tobias
_______________________________________________
Isak Hansen
> Database programs, usually, do not just issue isolated SQL statements, but
> implement a processing logic with nested queries and DML statements.
Frequently using cursors or issuing queries from a loop often means
you've missed out on the declarative and set based nature of SQL and
databases.
http://www.sqlservercentral.com/articles/T-SQL/66097/
http://stackoverflow.com/questions/287445/why-do-people-hate-sql-cursors-so-much
Granted, you could still argue that it should be supported, for the
few cases where it actually makes sense.
Isak
Tobias Schoofs
both references are very interesting.
If I understand correctly, the DSH approach is to convert Haskell
programs into SQL and run them inside the database. This seems a good
solution when the program objective is to change data in the database
according to some business logic or to preprocess relational data to
create a non-relational temporary resultset which is later used by an
external procedure.
The persistent way, from this perspective, appears to be more
"conventional" - data are obtained from the database to be processed by
an external program and presented on a website, for instance. Similar to
Takusen, the main objective here appears to be compile-time guarantees
on database types. Indeed, in a functional program, the string-based
embedded SQL is the weakest link in the chain. persistent strengthens
this link.