Database interface

[Thomas L. Bevan]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This type of interface is fine as far as it goes, but there is only=20
ever a loose coupling between the database and application.

The HaskellDB work implemented a relational calculus that ensured
that all queries were checked at compile time for validity against
a particular database.

The problem with HaskellDB is that it defines a join operator that=20
generates new types.

Tom

On Wed, 13 Aug 2003 02:02 am, Tom Pledger wrote:
> Thomas L. Bevan writes:
>  | Does anyone know if there is work being done on a standard Haskell
>  | database interface.
>
> I suspect that there isn't.  The pattern seems to be that someone gets
> an interface working well enough for some purposes, and perhaps shares
> it, but is too modest and/or busy to put it forward as a standard.
>
> For a row extraction mechanism, I'd vote for passing an extraction
> function (or IO action) to the main query function, like Tim Docker
> described last month.
>
>     http://haskell.cs.yale.edu/pipermail/haskell-cafe/2003-July/004684.ht=
ml
>
> This is a pretty good way to stop those nasty vague SQL row types at
> the Haskell border and turn them into something respectable.  Perhaps
> it would even be worth constraining the extracted type to be in
> DeepSeq
>
>     doquery :: (DeepSeq v) =3D>
>                Process -> String -> IO v -> IO [v]
>
> so that the interface clearly may confine its attention to one row at
> a time per cursor.
>
> - Tom
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Oj51Yha8TWXIQwoRAq0EAKCdfxWtB+D6cmZyOr7udXTXZtEgqQCgqIJM
rvLjcYXJouR0Q59XkyC4/L4=3D
=3D7F1i
=2D----END PGP SIGNATURE-----