Tom Pledger wrote:
How about introducing a Cursor abstract data type?
doquery :: Process -> String -> b -> (Cursor -> b -> IO (b, Bool)) -> IO b stringv :: Cursor -> CInt -> IO String doublev :: Cursor -> CInt -> IO Double intv :: Cursor -> CInt -> IO Int
This achieves the restriction you're after, because doquery is the only exported producer of Cursor, and stringv etc. are the only exported consumers of Cursor.
I like this. Not sure about whether I'd call it Cursor or just Row. Code something like results <- doquery dbconn sqltext [] \row results -> do name <- colv row 1 address <- colv row 2 return (name,address):results seems quite tidy.
It also has the benefit that the function you pass to doquery can make other calls to doquery, without mucking up the 'current row' state. There would be one current row per Cursor, not one per Process.
Is it normal or common to support multiple simultaneous queries on a single DB connection? Tim
Tim Docker writes: : | Is it normal or common to support multiple simultaneous queries on | a single DB connection? In transaction processing, yes. There's an idiom where you use one query to select all the (financial) transactions in a batch, but there's so much variation in how you need to process each row, that you can't express it all in one SQL query. So you use a variety of little queries during the processing of each row of the main query. The result of the fold in your doquery could be, say, a record of batch totals. - Tom
participants (2)
-
Tim Docker -
Tom Pledger