I just reread Dima's answer to my query about the database access in
particular and am confused. Dima says that he can't allow queries
outside the IOMonad because he has to worry about freeing memory (query
output).
However, Haskell/Com (built on top of Greencard?) seems to be able to
propagate garbage collection information from Haskell to C so that
when a Haskell/COM Object is no longer in use, there is some functionality
decrements its reference counter automatically.
How does this work? and can dima use this mechamism to free queries
when they are no longer needed? ..allowing database queries outside
the IOMonad?
-Alex-
PS The answer to this question is related to my prior unanswered question
on laziness and middleware.
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
On Tue, 26 May 1998 [EMAIL PROTECTED] wrote:
> >* SQL: many industrial strength databases provide a snapshot mode where
> >the state of the database doesn't change for the duration of the
> >connection.� I accept that opening a connection may need to be within a
> >do sequence. It doesn't make sense to me that SQL select queries should
> >be.� They are functions over a database datastructure in the same way one
> >might write functions over lists. (based on looking at the ODBC lib from
> >Dima Skvortsov <[EMAIL PROTECTED]>)
>
> I would respond to particularily this question as long as I am still working
> on this ODBC lib. (BTW note my new e-mail is address: [EMAIL PROTECTED],
> the one you mentioned above is not valid any more)
> Feel free to mail me if there are any problems/comments/... with this lib.
>
> Considering SQL queries that do not change state, it seems to me not so easy
> to get rid of putting them into monadic action.
> First of all you need to connect to database first, _then_ perform some SQL
> queries and _then_ disconnect. There is no sense in performing queries
> before connecting. Monad allows to synchronize these steps.
> Second, every SQL statement has its unique identifier (C type is HSTMT).
> It's created with function SQLAllocStmt and should be freed later with
> SQLFreeStmt. This identifier should be kept all the time to obtain query
> results or change parameters or run the query once more.
> Third, this identifier is not the only thing associated with a
> semi-stateless SQL statements. SQL statement identifier must be binded with
> memory buffers to obtain query results or set query parameters. Freeing this
> memory especially in case of fetching data is pretty difficult matter. Note
> that lazy list which represents the data being fetched can be evaluated to
> the end as well as left partly unevaluated. It depends on how many rows were
> fetched or how many elements of the list were binded within strict
> functions. Memory buffers should be freed when the list is fully evaluated
> or when the statement is closed. The best solution to that problem that I
> found required me to maintain an IO reference to the list of allocated
> memory with the SQL statement identifier. Obviously it's not possible
> without monad.
>
> Best regards,
> ��� Dima Skvortsov
>
>
>
