Library for accessing and storing data in databases.
It is based on the library Dynamic but ensures that
all changes to the database are only performed inside a transaction.
All functions in this library distinguishes between queries that
access the database and transactions that manipulates data
in the database. Transactions have a monadic structure.
Both queries and transactions can be executed as I/O actions.
However, arbitrary I/O actions cannot be embedded in transactions.
Author: Michael Hanus
Version: March 2008
| Exported names: |
Datatypes:
Query
| TError
| TErrorKind
| Transaction
Constructors:
DuplicateKeyError
| ExecutionError
| KeyNotExistsError
| KeyRequiredError
| MaxError
| MinError
| NoRelationshipError
| TError
| UniqueError
| UserDefinedError
Functions:
addDB
| deleteDB
| doneT
| dynamicExists
| errorT
| failT
| getDB
| mapT
| mapT_
| queryAll
| queryJustOne
| queryOne
| queryOneWithDefault
| returnT
| runJustT
| runQ
| runT
| runTNA
| sequenceT
| sequenceT_
| showTError
| transformQ
| |>>
| |>>=
| Summary of exported functions: |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
| Imported modules: |
| Exported datatypes: |
Abstract datatype to represent database queries.
Constructors:
The type of errors that might occur during a transaction.
Constructors:
:: TErrorKind -> String -> TError
The various kinds of transaction errors.
Constructors:
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
:: TErrorKind
Abstract datatype for representing transactions.
Constructors:
| Exported functions: |
:: (a -> Dynamic) -> Query [a]
A database query that returns all answers to an abstraction on a dynamic expression.
:: (a -> Dynamic) -> Query (Maybe a)
A database query that returns a single answer to an abstraction on a dynamic expression. It returns Nothing if no answer exists.
:: a -> (a -> Dynamic) -> Query a
A database query that returns a single answer to an abstraction on a dynamic expression. It returns the first argument if no answer exists.
:: (a -> Dynamic) -> Query a
A database query that returns a single answer to an abstraction on a dynamic expression. It fails if no answer exists.
:: Dynamic -> Query Bool
A database query that returns True if there exists the argument facts (without free variables!) and False, otherwise.
:: (a -> b) -> Query a -> Query b
Transforms a database query from one result type to another according to a given mapping.
:: Query a -> IO a
Executes a database query on the current state of dynamic predicates. If other processes made changes to persistent predicates, these changes are read and made visible to the currently running program.
:: TError -> String
Transforms a transaction error into a string.
:: Dynamic -> Transaction ()
Adds new facts (without free variables!) about dynamic predicates. Conditional dynamics are added only if the condition holds.
:: Dynamic -> Transaction ()
Deletes facts (without free variables!) about dynamic predicates. Conditional dynamics are deleted only if the condition holds.
:: Query a -> Transaction a
Returns the result of a database query in a transaction.
:: a -> Transaction a
The empty transaction that directly returns its argument.
:: Transaction ()
The empty transaction that returns nothing.
:: TError -> Transaction a
Abort a transaction with a specific transaction error.
:: String -> Transaction a
Abort a transaction with a general error message.
:: Transaction a -> (a -> Transaction b) -> Transaction b
Sequential composition of transactions.
Example call: (a |>>= fa)
a
- a transaction
fa
- a function from a value into a transaction
a
(yielding result r)
and then performs (fa r)
:: Transaction a -> Transaction b -> Transaction b
Sequential composition of transactions.
Example call: (a1 |>> a2)
a1
- a transaction
a2
- a transaction
:: [Transaction a] -> Transaction [a]
Executes a sequence of transactions and collects all results in a list.
:: [Transaction a] -> Transaction ()
Executes a sequence of transactions and ignores the results.
:: (a -> Transaction b) -> [a] -> Transaction [b]
Maps a transaction function on a list of elements. The results of all transactions are collected in a list.
:: (a -> Transaction b) -> [a] -> Transaction ()
Maps a transaction function on a list of elements. The results of all transactions are ignored.
:: Transaction a -> IO (Either a TError)
Executes a possibly composed transaction on the current state
of dynamic predicates as a single transaction.
Before the transaction is executed, the access to all persistent
predicates is locked (i.e., no other process can perform a
transaction in parallel).
After the successful transaction, the access is unlocked so that
the updates performed in this transaction become persistent and
visible to other processes.
Otherwise (i.e., in case of a failure or abort of the transaction),
the changes of the transaction to persistent predicates are
ignored and Nothing is returned.
In general, a transaction should terminate and all failures inside
a transaction should be handled (execept for an explicit failT
that leads to an abort of the transaction).
If a transaction is externally interrupted (e.g., by killing the process),
some locks might never be removed. However, they
can be explicitly removed by deleting the corresponding lock files
reported at startup time.
:: Transaction a -> IO a
Executes a possibly composed transaction on the current state
of dynamic predicates as a single transaction.
Similarly to runT but a run-time error is raised
if the execution of the transaction fails.
:: Transaction a -> IO (Either a TError)
Executes a possibly composed transaction as a Non-Atomic(!)
sequence of its individual database updates.
Thus, the argument is not executed as a single transaction
in contrast to runT, i.e., no predicates are
locked and individual updates are not undone in case of a
transaction error.
This operation could be applied to execute a composed transaction
without the overhead caused by (the current implementation of)
transactions if one is sure that locking is not necessary
(e.g., if the transaction contains only database reads and
transaction error raising).