>The reason I am using Transaction rather than Connection is because I am
>assuming that the database provides a transaction isolation model in which
>the database is required to remain in the same state (from the point
>of view of the client) until the transaction is committed.� Therefore any
>function which does queries can be assured of referential transparency for
>the duration of the transaction.� In the mail I sent, I included a
>transact function which takes (transaction -> [SQLChange]) as an argument
>and applies the changes in the order specified by the list.
>
Let's not confuse something green with something hot:)
Neither me nor anybody else in this list uses term Connection rather than Transaction.
Suppose we use ODBC to work with database.
The process starts from loading ODBC DLLs, initialization of them.
Next client must connect to data source. This causes loading of proper ODBC driver and
takes pretty long time.
After connection was established client program is able to run SQL statements on this
data source. What's the difference between Statement and Transaction? ODBC provides
two modes - Automatic and Manual. Automatic is default mode which runs any Statement
being executed on database immediately. Manual mode keeps executed Statements until
they are all fired by SQLTransact call. That's all the difference. It doesn't matter
what DBMS one is working with as long as it is treated as ODBC source. No difference
between dBase III and Oracle 8 ;))
Next� - obtaining data. One can say that SQL query doesn't change database state.
There are some more difficult questions about this.
First ODBC scheme is connect - run query - get data - disconnect.
You have to get data as IO action unless you incorporate all these scheme within
unsafePerformIO call. Otherwise you will be surprised getting data before running
query.
Second, World is changing even when database is not. Consider fetching data. Imagine
you are going to fetch table of 10...0 rows. Traditional ODBC scheme is allocate
memory buffers, bind them with table columns and fetch data row by row. Haskell can't
fetch data row by row to memory buffers.� I used lazy list in my Haskell-ODBC
interface to achieve this. Thus I allocate memory (IO action), bind it with columns
(IO action) and return suspended _IO_action_. The action being returned is to fetch
row of table (IO action again). And at last memory must be freed (once more IO action).
You see that suspension is IO action.
>My instinct is that it should be possible to automatically-serialize
>haskell datastructures into an SQL database if they derive Read and Show.
>It should also be possible to translate list comprehensions into a
>combination of server side SQL Select and client side Haskell.� However,
>that really is research.�
>
Depends on what do you mean by automatically. It seems not to be so hard since most
ODBC drivers support representing almost all of the possible types as strings. Just
create table and put there strings with my interface :)
Best regards,
��� Dima Skvortsov
