Re: [Haskelldb-users] 'IN' operator

[Bjorn B. <bri...@cs...>]

On Jul 6, 2006, at 8:44 AM, Matthias Radestock wrote:

> Bjorn,
>
> thanks for your quick response.
>
> Bjorn Bringert <bri...@cs...> writes:
>
>> t <- ...
>> restrict (foldr (\x y -> t!field .=3D=3D. x .||. y) (const True) =
values)
>
> This works fine, once I replaced the 'True' with 'False' ;)

Hehe, oops. I told you it was off the top of my head...


> I had a brief look at what it would take to support 'in' properly. =20
> It's
> not entirely clear to me what the best approach would be. Making =20
> [Expr]
> an instance of PrimExpr?

I went to check what needed to be done for it, and ended up =20
implementing it instead. It's in darcs now, but completely untested. =20
I added a new "_in" operator. Could you give it a spin and see if it =20
does the right thing?


> Another question: I am running some db queries inside haskell-fastcgi
> and am having a hard time figuring out when db connections get
> established. My program looks like this
>
>>  main =3D dbQuery (\db -> runFastCGIorCGI $ fetch db)
>>  dbQuery =3D dynConnect_ "postgresql" someOptions
>
> where 'fetch' does CGI and DB actions (the latter with 'liftIO').
>
> Does this end up establishing just *one* db connection, or one per
> request?  If the former, when does the data get committed?

If you run the connect function "outside" the runFastCGIorCGI, you =20
will only have one database connection set up for the life of that =20
process. If you want to connect once for every request, put it inside =20=

instead. When data is committed when you use persistent connections =20
may vary depending on the back-end. Using "transaction" should make =20
sure that it's committed with any back-end.

/Bj=F6rn