Alistair Bayley wrote:
Still making slow progress on an Oracle database binding...
now I'm trying to fit the API I have into some sort of
abstract interface (like the one(s) discussed previously:
Since the previous dicussion I've discovered Krasimir
Angelov's HSQL interface as part of his
a
database interface ought to look?
-Original Message-
From: Tim Docker [mailto:[EMAIL PROTECTED]
Sent: 29 September 2003 13:43
To: Bayley, Alistair; [EMAIL PROTECTED]
Subject: RE: Database interface - would like advice on oracle library
bind ing
Alistair Bayley wrote:
Still
The following code illustrates a _generic_ interface to low-level
database code. The left-fold iterator doQuery is completely generic
over any possible iterator -- no matter how many columns the query
returns, what are the types of these columns and what is the type of
the seed (accumulator). The
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
I'd like to remark first that many real databases let us avoid opening
many cursors at once. It seems to be more efficient to do as much as
possible within the engine ...
I agree (and Tom Pledger makes the same comment). It's rare that I
Here's another: ...
Make getInt (and friends) behave differently depending on the mode
of the cursor they're passed: either allocate a buffer and return
_|_, decode and return the current column of the current row, or
free a buffer and return _|_.
Not wanting to sound
Tom Pledger wrote:
How about introducing a Cursor abstract data type?
doquery :: Process - String - b - (Cursor - b - IO (b,
Bool))
- IO b
stringv :: Cursor - CInt - IO String
doublev :: Cursor - CInt - IO Double
intv:: Cursor - CInt - IO Int
From: Tim Docker [mailto:[EMAIL PROTECTED]
It also has the benefit that the function you pass to doquery can
make
other calls to doquery, without mucking up the 'current row' state.
There would be one current row per Cursor, not one per Process.
Is it normal or common to support
Tim Docker writes:
:
| Is it normal or common to support multiple simultaneous queries on
| a single DB connection?
In transaction processing, yes. There's an idiom where you use one
query to select all the (financial) transactions in a batch, but
there's so much variation in how you need to
Tim Docker writes:
:
| The list being folded over
| is implied by the DB query, is accessible through the IO monad.
| Hence a parameter is not required. It would really be:
|
| doquery :: Process - String - b - (b - IO (b,Bool)) - IO b
:
| One thing that I am unsure about is whether the
Tom Pledger writes:
By the way, how does the a in a - b - IO (b, Bool) work?
It looks like it has something to do with the current row. Does
doquery have to accommodate any possible substitution for a ?
I fired this off without thinking about it too much, and looking
at the prelude type
[EMAIL PROTECTED] wrote:
If I may interject, that's precisely how a Scheme DB interface is
designed. The main function is a left-fold. Not quite though: it
provides for a premature termination:
A major procedure: DB1:fold-left PROC INITIAL-SEED QUERY-OBJECT
Premature termination sounds
I'll probably generalise the query function to do a fold, rathen than
always accumulate a list:
doquery :: Process - String - (a - b - IO b) - b - IO b
If I may interject, that's precisely how a Scheme DB interface is
designed. The main function is a left-fold. Not quite though: it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I still want to use HaskellDB (or at least the relational calculus part of
it), so I was thinking of splitting it into two pieces: a library that
submits SQL queries and returns the results (database interface), and a
library that constructs
Tim Docker writes:
| Tom Pledger writes:
|
| This is a pretty good way to stop those nasty vague SQL row types at
| the Haskell border and turn them into something respectable. Perhaps
| it would even be worth constraining the extracted type to be in
| DeepSeq
|
| doquery
Tom Pledger writes:
This is a pretty good way to stop those nasty vague SQL row types at
the Haskell border and turn them into something respectable. Perhaps
it would even be worth constraining the extracted type to be in
DeepSeq
doquery :: (DeepSeq v) =
Process -
-Original Message-
From: Thomas L. Bevan [mailto:[EMAIL PROTECTED]
This type of interface is fine as far as it goes, but there is only
ever a loose coupling between the database and application.
The HaskellDB work implemented a relational calculus that ensured
that all queries
16 matches
Mail list logo
