Transactions

There are four transaction (write) operations:

A document looks like this:

In practice when using Crux, one calls crux.db/submit-tx with a sequence of transaction operations:

If the transaction contains CAS operations, all CAS operations must pass their pre-condition check or the entire transaction is aborted. This happens at the query node during indexing, and not when submitting the transaction.

For operations containing documents, the id and the document are hashed, and the operation and hash is submitted to the tx-topic in the event log. The document itself is submitted to the doc-topic, using its content hash as key. In Kafka, the doc-topic is compacted, which enables later deletion of documents.

The following types of :crux.db/id are allowed:

The #crux/id reader literal will take any string and attempt to coerce it into a valid ID. Use of #crux/id with a valid ID type will also work (e.g. {:crux.db/id #crux/id :my-id}).

URIs and URLs are interpreted using Java classes (java.net.URI and java.net.URL respectively) and therefore you can also use these directly.

Put’s a document into Crux. If a document already exists with the given :crux.db/id, a new version of this document will be created at the supplied valid time.

Note that valid time is optional and defaults to transaction time, which is taken from the Kafka log.

Crux currently writes into the past at a single point, so to overwrite several versions or a range in time, one is required to submit a transaction containing several operations.

The CAS operation (compare and swap) swaps an existing document version with a newer one, if the existing document is as expected.

Deletes a document at a given valid time. Historical version of the document will still be available.

Evicts a document from Crux. The transaction history will be available, but all versions at or before the provided valid time are evicted.

The evict transaction also supports additional parameters for straightforward eviction across time periods.