Database connection laziness (yesod)
Another lazy question:
fun :: Int -> Int
foo a = runReader ask (fun a)
bar a = runReader (return 3) (fun a)
foo causes (fun a) to be evaluated but bar doesn't. Is the same true for database connections? Are they created lazily? I ask because it would be neat to be able to write:
runDB $ getFromCache cache key
where getFromCache queries the DB only on a cache miss, and have a connection created only in the case of a cache miss. I have tried test this myself, but I can't get ghci to cooperate and load yesod from source. Cheers, J
On Tue, May 17, 2011 at 7:32 PM, Jeremy Hughes
I ask because it would be neat to be able to write:
runDB $ getFromCache cache key
where getFromCache queries the DB only on a cache miss, and have a connection created only in the case of a cache miss.
IIRC, runDB runs on a pool of DB connections, so it never creates a connection, it only grabs one connection from the pool. That said, runDB needs to get a connection from the pool even if you don't use it all. Also, it needs to start and commit a transaction (although I guess that drivers may optimize away the commit knowing that you didn't do anything). So while a connection startup/teardown cycle won't be needed, you will need to use the resource that other thread could be using. Does that make sense? I'm not sure if all I've said is correct, but I think so. Cheers, =) -- Felipe.
Hi Felipe,
On Wed, May 18, 2011 at 12:25 PM, Felipe Almeida Lessa
IIRC, runDB runs on a pool of DB connections, so it never creates a connection, it only grabs one connection from the pool.
Ah, yes. My mistake.
That said, runDB needs to get a connection from the pool even if you don't use it all. Also, it needs to start and commit a transaction (although I guess that drivers may optimize away the commit knowing that you didn't do anything). So while a connection startup/teardown cycle won't be needed, you will need to use the resource that other thread could be using.
Does that make sense? I'm not sure if all I've said is correct, but I think so.
Makes sense to me.
participants (2)
-
Felipe Almeida Lessa -
Jeremy Hughes