Abstract monad for writing and evaluating queries under ACID semantics.

The l parameter stands for a LogState backend, m is a MonadIO that gets lifted, so users can run arbitrary IO inside queries, and a is the result.

Transaction evaluation inside a MonadIO.

Lookups are executed directly, targeting a specific version (TransactionId) , while the keys of both read and written documents are collected in the TransactionState.

At the end various consistency checks are performed, and the transaction is aborted in case any fails. See TransactionAbort for details.

Otherwise, under master lock, space in the data (abstract) file is allocated with alloc, and the transaction records are written in the logPend, and also in the log file, with logAppend.

Writing the serialized data to the data file, updating indexes and completing the transaction is then left for the commitThread. Note that transactions are only durable after commitThread finishes. In the future we may add a blocking version of runQuery.

Error returned by runQuery for aborted transactions.

It is an instance of Exception solely for user convenience, as the database never throws it.

Dereferences the given key. Returns Nothing if the key is not found.

Inserts a new document and returns its key.

The primary key is generated with mkNewDocumentKey.

Updates a document.

Note that since muesli is a MVCC database, this means inserting a new version of the document. The version number is the TransactionId of the current transaction. This fact is transparent to the user though.

Deletes a document.

Note that since muesli is a MVCC database, this means inserting a new version with the recDeleted flag set to True. But this fact is transparent to the user, since the indexes are updated as if the record was really deleted.

It will be the job of the gcThread to actually clean the transaction log and compact the data file.

Sort order for range queries.

Runs a range query on a Sortable field.

It can be used as a cursor, for precise and efficient paging through a large dataset. For this purpose you should remember the last Reference from the previous page and give it as the sortKey argument below. This is needed since the sortable field may not have unique values, so remembering just the sortVal is insufficient.

The corresponding SQL is:

SELECT TOP page * FROM table
WHERE (sortVal = NULL OR sortFld < sortVal) AND (sortKey = NULL OR ID < sortKey)
ORDER BY sortFld, ID sortOrder

Like range, but returns only the keys.

Runs a filter-and-range query on a Reference field, with results sorted on a different Sortable field.

Sending Nothing for filterVal filters for NULL values, which correspond to a Nothing in a field of type Maybe (Reference a). This uses the special Maybe instance mentioned at the Indexable documentation.

The paging behaviour is the same as for range.

The corresponding SQL is:

SELECT TOP page * FROM table
WHERE (filterFld = filterVal) AND
      (sortVal = NULL OR sortFld < sortVal) AND (sortKey = NULL OR ID < sortKey)
ORDER BY sortFld, ID sortOrder

Like filterRange, but returns only the keys.

Runs a filter query on a Reference field, with results sorted on a different Sortable field.

Like filterRange, but returns all documents, not just a range.

Like filter, but returns only the keyes.

Returns a document uniquely determined by the given Unique key value, or Nothing if the key is not found.

Returns a Reference to a document uniquely determined by the given Unique key value, or Nothing if the key is not found.

Performs a unique' and then, depending whether the key exists or not, either inserts or updates the respective document.

Returns the number of documents of type a in the database.