Haskell ODBC interface is now available on the web.
See http://members.tripod.com/~sproot/hasql.htm
I beleive I have already sent announce, but I've got no
copy of that mail from Haskell mailing list. Maybe something wrong with my mail.
Once more I admit that my code is overflooded with checking where and when to call
finalizer=destructor=...
Using foreign objects could make it pretty much simpler.
Should they be considered to be some kind of standard?
Ok, let's go to "stateless" SQL statements.
Where would you like to connect to database?
Will it be affordable to connect and disconnect in
sqlSelect or doTransaction functions proposed by you?
What structure are you going to use to retreive data.
I used lazy list (of tuples or of lists). What will be placed to this list when its
evaluation is forced after disconnecting from database? Does this mean one have to
choose between lazy data structure and connecting-query-disconnecting as a single IO
action?
I found no answers to this question, but implementing connection, query, data
fetching and disconnection as a separate IO actions.
Best regards,
Dima Skvortsov
---- you wrote:
> 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.
> >
> > ___________________________________________________________________
