SqlValue is he main type for expressing Haskell values to SQL databases.

INTRODUCTION TO SQLVALUE

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 constructed with the most appropriate SqlValue constructor. fromSql or safeFromSql can then be used to convert them into whatever type is needed locally in Haskell.

Most people will use toSql and fromSql instead of manipulating SqlValues directly.

EASY CONVERSIONS BETWEEN HASKELL TYPES

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.

Conversions are implemented in terms of the Data.Convertible module, part of the convertible package. You can refer to its documentation, and import that module, if you wish to parse the Left result from safeFromSql yourself, or write your own conversion instances.

Here are some notes about conversion:

• Fractions of a second are not preserved on time values
• There is no safeToSql because toSql never fails.

See also toSql, safeFromSql, fromSql, nToSql, iToSql, posixToSql.

ERROR CONDITIONS

There may sometimes be an error during conversion. For instance, if you have a SqlString and are attempting to convert it to an Integer, but it doesn't parse as an Integer, you will get an error. This will be indicated as an exception if using fromSql, or a Left result if using safeFromSql.

SPECIAL NOTE ON POSIXTIME

Note that a NominalDiffTime or POSIXTime is converted to SqlDiffTime by toSql. HDBC cannot differentiate between NominalDiffTime and POSIXTime since they are the same underlying type. You must construct SqlPOSIXTime manually or via posixToSql, or use SqlUTCTime.

DETAILS ON SQL TYPES

HDBC database backends are expected to marshal date and time data back and forth using the appropriate representation for the underlying database engine. Databases such as PostgreSQL with builtin date and time types should see automatic conversion between these Haskell types to database types. Other databases will be presented with an integer or a string. Care should be taken to use the same type on the Haskell side as you use on the database side. For instance, if your database type lacks timezone information, you ought not to use ZonedTime, but instead LocalTime or UTCTime. Database type systems are not always as rich as Haskell. For instance, for data stored in a TIMESTAMP WITHOUT TIME ZONE column, HDBC may not be able to tell if it is intended as UTCTime or LocalTime data, and will happily convert it to both, upon your request. It is your responsibility to ensure that you treat timezone issues with due care.

This behavior also exists for other types. For instance, many databases do not have a Rational type, so they will just use the show function and store a Rational as a string.

The conversion between Haskell types and database types is complex, and generic code in HDBC or its backends cannot possibly accomodate every possible situation. In some cases, you may be best served by converting your Haskell type to a String, and passing that to the database.

UNICODE AND BYTESTRINGS

Beginning with HDBC v2.0, interactions with a database are presumed to occur in UTF-8.

To accomplish this, whenever a ByteString must be converted to or from a String, the ByteString is assumed to be in UTF-8 encoding, and will be decoded or encoded as appropriate. Database drivers will generally present text or string data they have received from the database as a SqlValue holding a ByteString, which fromSql will automatically convert to a String, and thus automatically decode UTF-8, when you need it. In the other direction, database drivers will generally convert a SqlString to a ByteString in UTF-8 encoding before passing it to the database engine.

If you are handling some sort of binary data that is not in UTF-8, you can of course work with the ByteString directly, which will bypass any conversion.

Due to lack of support by database engines, lazy ByteStrings are not passed to database drivers. When you use toSql on a lazy ByteString, it will be converted to a strict ByteString for storage. Similarly, fromSql will convert a strict ByteString to a lazy ByteString if you demand it.

EQUALITY OF SQLVALUE

Two SqlValues are considered to be equal if one of these hold. The first comparison that can be made is controlling; if none of these comparisons can be made, then they are not equal:

• Both are NULL
• Both represent the same type and the encapsulated values are considered equal by applying (==) to them
• The values of each, when converted to a string, are equal.

STRING VERSIONS OF TIMES

Default string representations are given as comments below where such are non-obvious. These are used for fromSql when a String is desired. They are also defaults for representing data to SQL backends, though individual backends may override them when a different format is demanded by the underlying database. Date and time formats use ISO8601 date format, with HH:MM:SS added for time, and -HHMM added for timezone offsets.

DEPRECATED CONSTRUCTORS

SqlEpochTime and SqlTimeDiff are no longer created automatically by any toSql or fromSql functions or database backends. They may still be manually constructed, but are expected to be removed in a future version. Although these two constructures will be removed, support for marshalling to and from the old System.Time data will be maintained as long as System.Time is, simply using the newer data types for conversion.

Convert a value to an SqlValue. This function is simply a restricted-type wrapper around convert. See extended notes on SqlValue.

Convert from an SqlValue to a Haskell value. Any problem is indicated by calling error. This function is simply a restricted-type wrapper around convert. See extended notes on SqlValue.

Conversions to and from SqlValues and standard Haskell types.

This function converts from an SqlValue to a Haskell value. Many people will use the simpler fromSql instead. This function is simply a restricted-type wrapper around safeConvert.

Converts any Integral type to a SqlValue by using toInteger.

Convenience function for using numeric literals in your program.

Convenience function for converting POSIXTime to a SqlValue, because toSql cannot do the correct thing in this instance.

Main database handle object.

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.

A connection is closed by a call to disconnect.

A call to commit is required to make sure that your changes get committed to the database. In other words, HDBC has no support for autocommit, which we consider an outdated notion.

Sometimes, it is annoying to use typeclasses with Haskell's type system. In those situations, you can use a ConnWrapper. You can create one with:

let wrapped = ConnWrapper iconn

You can then use this directly, since a ConnWrapper is also an IConnection. However, you will not be able to use private database functions on it.

Or, you can use withWConn.

Unwrap a ConnWrapper and pass the embedded IConnection to a function. Example:

withWConn wrapped run $ "SELECT * from foo where bar = 1" []

Like run, but take a list of Maybe Strings instead of SqlValues.

Strict version of quickQuery.

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

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 commit or 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.

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 statement as-is, without supplying any positional parameters. This is intended for statements for which the results aren't interesting or present (e.g., DDL or DML commands). If your query contains placeholders, this will certainly fail; use execute instead.

Like execute, but take a list of Maybe Strings instead of SqlValues.

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.

This is most useful for non-SELECT statements.

Like executeMany, but take a list of Maybe Strings instead of SqlValues.

Fetches one row from the DB. Returns Nothing if there are no more rows. Will automatically call finish when the last row is read.

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.

Similar to fetchRowAL, but return a Map instead of an association list.

Like fetchRow, but return a list of Maybe Strings instead of SqlValues.

Lazily fetch all rows from an executed Statement.

You can think of this as hGetContents applied to a database result set.

The result of this is a lazy list, and each new row will be read, lazily, from the database as the list is processed.

When you have exhausted the list, the Statement will be finished.

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.

Strict version of fetchAllRows. Does not have the side-effects of fetchAllRows, but forces the entire result set to be buffered in memory.

Like fetchAllRows, but instead of returning a list for each row, return an association list for each row, from column name to value.

See fetchRowAL for more details.

Strict version of fetchAllRowsAL

Like fetchAllRowsAL, but return a list of Maps instead of a list of association lists.

Strict version of fetchAllRowsMap

Like fetchAllRows, but return Maybe Strings instead of SqlValues.

Strict version of sFetchAllRows.

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.

Obtain information about the columns in the result set. Must be run only after execute. The String in the result set is the column name.

You should expect this to be returned in the same manner as a result from fetchAllRows'.

All results should be converted to lowercase for you before you see them.

Please see caveats under getColumnNames for information on the column name field here.

Abort a query in progress -- usually not needed.

The original query that this Statement was prepared with.

The main HDBC exception object. As much information as possible is passed from the database through to the application through this object.

Errors generated in the Haskell layer will have seNativeError set to -1.

A utility function to throw a SqlError. The mechanics of throwing such a thing differ between GHC 6.8.x, Hugs, and GHC 6.10. This function takes care of the special cases to make it simpler.

With GHC 6.10, it is a type-restricted alias for throw. On all other systems, it is a type-restricted alias for throwDyn.

Execute the given IO action.

If it raises a SqlError, then execute the supplied handler and return its return value. Otherwise, proceed as normal.

Like catchSql, with the order of arguments reversed.

Given an Exception, return Just SqlError if it was an SqlError, or Nothing otherwise. Useful with functions like catchJust.

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.