Thanks to you, Alastair Reid and Sven Panne who pointed me to foreign
objects and made things clear about them. I agree, using foreign objects could make
my code simpler. Hope I will have some time to do this.
Anyway this doesn't make untyped buffers less stateful.
They still have to be created before fetching starts, maintained all the time query is
being fetched and then freed. This is still IO action.
The only way I see to get the pure function, performing fetching from database is to
follow Simons advice and put it alltogether within unsafePerformIO call. But it seems
to be pretty expansive to connect to ODBC source and disconnect every time you want to
get some data. Most times connecting will cause loading a number of dlls.
Best regards,
� Dima Skvortsov
-----------------------------
From: S. Alexander Jacobson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
Subject: Garbage Collection in GreenCard/RedCard/HaskellCOM
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
>
>
>
