# Reads And Writes
Most of the methods in SDKs have Verified
equivalent, i.e. Get
and VerifiedGet
. The only difference is that with Verified
methods proofs needed to mathematically verify that the data was not tampered are returned by the server and the verification is done automatically by SDKs.
Note that generating that proof has a slight performance impact, so primitives are allowed without the proof.
It is still possible to get the proofs for a specific item at any time, so the decision about when or how frequently to do checks (with the Verify version of a method) is completely up to the user.
It's possible also to use dedicated auditors to ensure the database consistency, but the pattern in which every client is also an auditor is the more interesting one.
# Get and Set
Get
/VerifiedGet
and Set
/VerifiedSet
methods allow for basic operations on a Key Value level.
# Get at and since a transaction
You can retrieve a key on a specific transaction with GetAt
/VerifiedGetAt
. If you need to check the last value of a key after given transaction (which represent state of the indexer), you can use GetSince
/VerifiedGetSince
.
# Get at revision
Each historical value for a single key is attached a revision number. Revision numbers start with 1 and each overwrite of the same key results in a new sequential revision number assignment.
A negative revision number can also be specified which means the nth historical value, e.g. -1 is the previous value, -2 is the one before and so on.
# Get at TXID
It's possible to retrieve all the keys inside a specific transaction.
# Filter Transactions
The transaction entries are generated by writing key-value pairs, referencing keys, associating scores to key-value pairs (with ZAdd
operation), and by mapping SQL data model into key-value model.
With TxByIDWithSpec
operation it's possible to retrieve entries of certain types, either retrieving the digest of the value assigned to the key (EntryTypeAction_ONLY_DIGEST
), the raw value (EntryTypeAction_RAW_VALUE
) or the structured value (EntryTypeAction_RESOLVE
).
# Conditional writes
immudb can check additional preconditions before the write operation is made. Precondition is checked atomically with the write operation. It can be then used to ensure consistent state of data inside the database.
Following preconditions are supported:
- MustExist - precondition checks if given key exists in the database, this precondition takes into consideration logical deletion and data expiration, if the entry was logically deleted or has expired, MustExist precondition for such entry will fail
- MustNotExist - precondition checks if given key does not exist in the database, this precondition also takes into consideration logical deletion and data expiration, if the entry was logically deleted or has expired, MustNotExist precondition for such entry will succeed
- NotModifiedAfterTX - precondition checks if given key was not modified after given transaction id, local deletion and setting entry with expiration data is also considered modification of the entry
In many cases, keys used for constraints will be the same as keys for written entries. A good example here is a situation when a value is set only if that key does not exist. This is not strictly required - keys used in constraints do not have to be the same or even overlap with keys for modified entries. An example would be if only one of two keys should exist in the database. In such case, the first key will be modified and the second key will be used for MustNotExist constraint.
A write operation using precondition can not be done in an asynchronous way. Preconditions are checked twice when processing such requests - first check is done against the current state of internal index, the second check is done just before persisting the write and requires up-to-date index.
Preconditions are available on SetAll
, Reference
and ExecAll
operations.