Why can't you provide a function like
sqlSelect::ODBCTransaction -> Query -> ODBCResult
The function itself does unsafePerformIO and returns an ODBCResult object.
When Haskell is done using this object, it will execute the foreignObject
garbage collection callback function. The gc call back function executes
haSQLFreeStmt.
This would allow you to define something like:
doTransaction::(ODBCTransaction -> ([ODBCUpdate],[ODBCInsert])) -> IO()
doTransaction takes a function that maps database state to a set of
inserts and updates, executes the function on an open transaction and
performs the database updates and inserts specified by the function.
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
On Thu, 18 Jun 1998 [EMAIL PROTECTED] wrote:
> 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
> >
> >
> >
>
>
>
