KvEntry type
KvQueueEntry type
Create a new NanoKV connection.
Current NanoKV endpoint
Specify a custom encoding method for values, by default it will use JSON as serialization format
Create a new AtomicOperation object which can be used to perform an atomic transaction on the database. This does not perform any operations on the database - the atomic transaction must be committed explicitly using the AtomicOperation.commit method once all checks and mutations have been added to the operation.
Delete the value for the given key from the database. If no value exists for the key, this operation is a no-op.
The key to delete.
Optional
signal: AbortSignalA promise resolving to an object containing a boolean indicating whether the operation was successful, and the versionstamp of the deleted key-value entry.
Retrieve the value and versionstamp for the given key from the database in the form of a KvEntryMaybe. If no value exists for the key, the returned entry will have a null value and versionstamp.
Optional
signal: AbortSignalRetrieve multiple values and versionstamp from the database in the form of an array of KvEntryMaybe objects. The returned array will have the same length as the keys array, and the entries will be in the same order as the keys. If no value exists for a given key, the returned entry will have a null value and versionstamp.
Optional
signal: AbortSignalRetrieve a list of keys in the database. The returned list is a NanoStream which can be used to iterate over the entries in the database. Each list operation must specify a selector which is used to specify the range of keys to return. The selector can either be a prefix selector, or a range selector:
The options argument can be used to specify additional options for the list operation. See the documentation for KvListOptions for more information.
Listen for queue values to be delivered from the database queue, which were enqueued with AtomicOperation.enqueue, you can spcify which keys to listen to.
You need to use AtomicOperation.dequeue to dequeue values from the queue after you have received and processed them, or you will get duplicates in next time you call this method.
The keys to listen to.
A readable stream of key-value pairs.
Set the value for the given key in the database. If a value already exists for the key, it will be overwritten.
Optionally an expireIn option can be specified to set a time-to-live (TTL) for the key. The TTL is specified in milliseconds, and the key will be deleted from the database at earliest after the specified number of milliseconds have elapsed. Once the specified duration has passed, the key may still be visible for some additional time. If the expireIn option is not specified, the key will not expire.
The key to set.
The value to set.
Options for the set operation.
Optional
expireIn?: numberThe number of milliseconds after which the key-value entry will expire.
Optional
signal?: AbortSignalGet a subspace of the database, operating on all key with the given prefix.
Watch for changes to the given keys in the database. The returned stream is a NanoStream that emits a new value whenever any of the watched keys change their versionstamp. The emitted value is an array of KvEntryMaybe objects, with the same length and order as the keys array. If no value exists for a given key, the returned entry will have a null value and versionstamp.
The returned stream does not return every single intermediate state of the watched keys, but rather only keeps you up to date with the latest state of the keys. This means that if a key is modified multiple times quickly, you may not receive a notification for every single change, but rather only the latest state of the key.
An array of keys to watch for changes.
A key-value database designed for efficient data storage and retrieval.
In this database, data is saved and accessed through key-value pairs. The key is a KvKey, and the value is any JavaScript object that can be structured and serialized. Keys are sorted lexicographically as per the KvKey documentation, and each key in the database is unique. When a key is read, the system returns the most recent value associated with it. Keys can be removed from the database, and upon deletion, they will no longer appear during read operations.
Values can be any JavaScript object that is structured-serializable, such as objects, arrays, strings, or numbers.
Each key is versioned upon writing by assigning it an ever-increasing "versionstamp". This versionstamp signifies the versionstamp of the key-value pair at a specific moment and facilitates transactional operations on the database without the need for locks. Atomic operations, which can include conditions to check against the expected versionstamp, ensure that the operation only completes if the versionstamp matches the anticipated value.
The NanoKV database also provides a lightweight message queue feature. Please note: Although the API names are similar to those of denokv, there are significant differences in their behaviors. For instance, denokv's message delivery is more inclined towards real-time processing, and thus denokv will attempt to redeliver to the consumer within a specific time frame (with settings for the number of retries and frequency). In contrast, NanoKV leans more towards the essence of a "queue", where consumers can retrieve outdated messages from the queue (if not manually dequeued), as well as receive new messages in real-time.
Additionally, NanoKV supports the existence of multiple queues simultaneously. Different parts of an application (such as various microservices) can listen only to the queues they are interested in, whereas denokv can only have a single global queue (for a denokv instance). This is also a significant difference.
Example