Re: [htoolkit-users] HSQL, HList

[Frederik E. <fre...@a5...>]

On Tue, Feb 22, 2005 at 10:18:03PM +0100, Bjorn Bringert wrote:
> Frederik Eaton wrote:
> >I wrote some functions which can be used with HSQL to make it a lot
> >more concise, using the HList concept:
> >
> >http://ofb.net/~frederik/SqlRow/
> >
> >If anybody wants to look at it and give feedback. Maybe it could be
> >incorporated into the library.
> 
> One difference to the current HSQL is that you access record fields by 
> position rather than by name. Not sure whether this is good or bad. One 
> problem is that there is as little type safety now as before, and it's 
> as easy to access a non-existing field.
> 
> The nice thing is that you can get back a whole row at a time, and I 
> like the pattern trick in:
> 
> getRows stmt >>=
>         mapM_ (\ (m :. n :. p :. Nil) ->
> 
> All in all I think it is a very good demonstration of what you can do 
> with heterogenous lists, and it's not really worse than HSQL when it 
> comes to type-safety.

Thanks.

> You might want to have a look at HaskellDB, 
> http://haskelldb.sourceforge.net/ . It uses a similar scheme for record 
> types. It adds a layer of type safety, and you construct the queries 
> using combinators.
> 
> You might want to be careful with collectRowsAsync. We have the same 
> thing in HaskellDB, and it turns out to be a problem with some databases 
> if you run a second query without getting all that data from the first 
> one. I think MySQL with the native drivers does it for example, but not 
> with ODBC.

About accessing record fields by name vs. position, that was one
reason I wanted to write this. I wasn't sure how to name fields with
expressions such as:

select min(a.s), avg(a.s), max(a.s), sum(a.s) from ...

and felt that it shouldn't be necessary either. Temporary names (X as
a, Y as b) are possible but cumbersome. Positional bindings seem more
lightweight and nimble and in tune with the rest of Haskell - they are
how function parameters are done, after all.

One thing that doesn't come out in the example is that it should also
be a lot easier to do assignments from singleton select statements as
above, with another utility function or two, which can be quite common
in database applications.

(min :. ave :. max :. sum :. Nil) <- doOneRow "select ..."

I've looked at HaskellDB, I was shying away from it because I thought
I needed a more direct mapping to SQL internals.

Thanks for the heads up on collectRowsAsync.

-- 
Frederik Eaton                         http://ofb.net/~frederik/