Introduction

Welcome to HDBC, Haskell Database Connectivity.

HDBC provides an abstraction layer between Haskell programs and SQL
relational databases. This lets you write database code once, in
Haskell, and have it work with any number of backend SQL databases
(MySQL, Oracle, PostgreSQL, ODBC-compliant databases, etc.)

Typing of transfer data

Conversions are powerful; for instance, you can call fromSql on a SqlInt32
and get a String or a Double out of it. This class attempts to Do
The Right Thing whenever possible, and will raise an error when asked to
do something incorrect. In particular, when converting to any type
except a Maybe, SqlNull as the input will cause an error to be raised.

This type is used to marshall Haskell data to and from database APIs.
HDBC driver interfaces will do their best to use the most accurate and
efficient way to send a particular value to the database server.

Values read back from the server are put in the most appropriate SqlValue
type. fromSql can then be used to convert them into whatever type
is needed locally in Haskell.

The default representation of time values is an integer number of seconds.
Databases such as PostgreSQL with builtin timestamp types can will see
automatic conversion between these Haskell types to local types. Other
databases can just use an int or a string.

This behavior also exists for other types. For instance, many databases don't
have a Rational type, so they'll just use Haskell's show function and
store a Rational as a string.

Two SqlValues are considered to be equal if one of these hold (first one that
is true holds; if none are true, they are not equal):
* Both are NULL
* Both represent the same type and the encapsulated values are equal
* The values of each, when converted to a string, are equal.

Database Connections

An IConnection object is created by specific functions in the module for an
individual database. That is, the connect function -- which creates
this object -- is not standardized through the HDBC interface.

You do not need to explicitly close an IConnection object, but you may do so if
you so desire. If you don't, the object will disconnect from the database
in a sane way when it is garbage-collected. However, a disconnection may
raise an error, so you are encouraged to explicitly call disconnect. Also,
garbage collection may not run when the program terminates, and some databases
really like an explicit disconnect.

So, bottom line is, you're best off calling disconnect directly, but the
world won't end if you forget.

This function discards any data not committed already. Database driver
implementators should explicitly call rollback if their databases don't
do this automatically on disconnect.

Bad Things (TM) could happen if you call this while you have Statements
active. In more precise language, the results in such situations are undefined
and vary by database. So don't do it.

Create a new Connection object, pointed at the same
server as this object is. This will generally establish
a separate physical connection.

When you wish to establish multiple connections to a single
server, the correct way to do so is to establish the
first connection with the driver-specific connection
function, and then clone it for each additional connection.

This can be important when a database doesn't provide
much thread support itself, and the HDBC driver module
must serialize access to a particular database.

This can also be a handy utility function whenever you
need a separate connection to whatever database you are
connected to already.

The name of the HDBC driver module for this connection.
Ideally would be the same as the database name portion
of the Cabal package name. For instance, "sqlite3"
or "odbc". This is the layer that is bound most
tightly to HDBC.

The version of the C (or whatever) client library
that the HDBC driver module is bound to. The meaning
of this is driver-specific. For an ODBC or similar
proxying driver, this should be the version of the
ODBC library, not the eventual DB client driver.

A quick way to do a query. Similar to preparing, executing, and
then calling fetchAllRows on a statement. See also quickQuery'

Transaction Handling

This section concerns itself with writing (updating) a database.

In HDBC, as with many RDBMS implementations, every write to the
database occurs within a transaction. No changes are visible (outside
the current transaction) until a commit operation occurs, in which
case all changes since the transaction started are atomically
committed. Also, there is a rollback operation that can undo all
changes since the transaction started.

HDBC does everything within a transaction. A transaction is implicitly entered
when a connection to a database is established, and a transaction is
implicitly entered after each call to commit or rollback as well.

The practical effect of this is that you must call commit after making
changes to a database in order for those changes to become visible. You don't
have to call commit after every change, just after a batch of them.

(Exceptions exist for databases that don't offer a high level of transaction
isolation; but you should always play it safe and commit anyway.)

Database developers will also be experienced with the atomicity benefits
of transactions, an explanation of which is outside the scope of this manual.

Errors occuring at the database level can leave a transaction in an
indeterminate state, depending on the database. Some databases will
refuse all queries until the next commit or rollback. The safe thing
to do is to issue a commit or rollback after trapping any SqlError.
Alternatively, you could use withTransaction, which will automatically
handle this detail for you.

Execute some code. If any uncaught exception occurs, run
rollback and re-raise it. Otherwise, run commit and return.

This function, therefore, encapsulates the logical property that a transaction
is all about: all or nothing.

The IConnection object passed in is passed directly to the specified
function as a convenience.

This function traps all uncaught exceptions, not just SqlErrors. Therefore,
you will get a rollback for any exception that you don't handle. That's
probably what you want anyway.

Since all operations in HDBC are done in a transaction, this function doesn't
issue an explicit "begin" to the server. You should ideally have
called Database.HDBC.commit or Database.HDBC.rollback before
calling this function. If you haven't, this function will commit or rollback
more than just the changes made in the included action.

If there was an error while running rollback, this error will not be
reported since the original exception will be propogated back. (You'd probably
like to know about the root cause for all of this anyway.) Feedback
on this behavior is solicited.

Connection Inquiries

Statements

Execution

Execute the prepared statement, passing in the given positional
parameters (that should take the place of the question marks
in the call to prepare).

For non-SELECT queries, the return value is the number of
rows modified, if known. If no rows were modified, you get 0.
If the value is unknown, you get -1. All current HDBC drivers
support this function and should never return -1.

For SELECT queries, you will always get 0.

This function should automatically call finish() to finish the previous
execution, if necessary.

Execute the query with many rows.
The return value is the return value from the final row
as if you had called execute on it.

Due to optimizations that are possible due to different
databases and driver designs, this can often be significantly
faster than using execute multiple times since queries
need to be compiled only once.

Like fetchRow, but instead of returning a list, return an association
list from column name to value.

The keys of the column names are lowercase versions of the data returned
by getColumnNames. Please heed the warnings there. Additionally,
results are undefined if multiple columns are returned with identical names.

Please note that the careless use of this function can lead to some unpleasant
behavior. In particular, if you have not consumed the entire list, then
attempt to finish or re-execute the statement, and then attempt to consume
more elements from the list, the result will almost certainly not be what
you want.

But then, similar caveats apply with hGetContents.

Bottom line: this is a very convenient abstraction; use it wisely.

Use fetchAllRows' if you need something that is strict, without
all these caveats.

Returns a list of the column names in the result.
For maximum portability, you should not assume that
information is available until after an execute function
has been run.

Information is returned here directly as returned
by the underlying database layer. Note that different
databases have different rules about capitalization
of return values and about representation of names
of columns that are not simple columns. For this reason,
it is suggested that you treat this information for
display purposes only. Failing that, you should convert
to lower (or upper) case, and use AS clauses for
anything other than simple columns.

A simple getColumnNames implementation could simply
apply map fst to the return value of describeResult.

Catches SqlErrors, and re-raises them as IO errors with fail.
Useful if you don't care to catch SQL errors, but want to see a sane
error message if one happens. One would often use this as a high-level
wrapper around SQL calls.

Threading

Thread support in a generalized interface such as HDBC can be complicated
because support for threading varies across database interfaces.

However, applications using HDBC should be able to rely upon at least a few
basic guarantees:

The HDBC modules may freely be imported and used across all threads.

HDBC modules may also freely share database connections and statements;
the database or HDBC driver will be responsible for locking if necessary.

I use "share" in the same sense as Python's DB-API: multiple threads may use
the resource without wrapping it in any lock.

However, there are some caveats to the above:

Not all databases support more than one active statement for a single
connection. Therefore, for maximum portability, you should use
a different connection to the database for each simultaneous query you
wish to use.
FIXME: describe when a statement is active.

Not all databases may support the level of multithreading described above.
For those that don't, safe access will be restriced in the HDBC driver
by using locks. Therefore, you can write portable code, but you
only get real multithreading when databases really support it.
Details of thread support should be documented in the HDBC
driver for each specific database.

Copyright and License

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA