odac 1.4.7 → 1.4.8

package/CHANGELOG.md

@@ -1,3 +1,20 @@
+### ✨ What's New
+
+- **database:** add Write-Behind Cache with counter, update, and batch insert buffering
+- **ipc,database:** extend Ipc with atomic ops and delegate WriteBuffer state to Ipc layer
+
+### 🛠️ Fixes & Improvements
+
+- atomic queue drain, transaction-safe flush, hgetall clone & unhandled rejection
+- **odac:** ensure proper token query parameter handling in get method
+- **storage:** ensure synchronous operations for put and remove methods
+
+
+
+---
+
+Powered by [⚡ ODAC](https://odac.run)
+
 ### ⚙️ Engine Tuning
 
 - **test:** remove unused fsPromises and standardize async I/O in View tests

package/client/odac.js

@@ -679,7 +679,7 @@ if (typeof window !== 'undefined') {
     }
 
     get(url, callback) {
-      url = url + '?_token=' + this.token()
+      url = url + (url.includes('?') ? '&' : '?') + '_token=' + this.token()
       this.#ajax({url: url, success: callback})
     }
 

package/docs/ai/README.md

@@ -24,7 +24,7 @@ Detailed instructions are organized into Backend and Frontend categories:
 - `backend/config.md`: Configuration management and environment variables.
 - `backend/controllers.md`: Request handling and Class-Based Controllers.
 - `backend/cron.md`: Scheduled background tasks and automation.
-- `backend/database.md`: High-performance query builder usage.
+- `backend/database.md`: High-performance query builder usage, Write-Behind Cache (buffered counters, last-write-wins updates, batch inserts).
 - `backend/forms.md`: Form processing and validation logic.
 - `backend/ipc.md`: Inter-Process Communication and state sharing.
 - `backend/mail.md`: Transactional email sending.

package/docs/ai/skills/SKILL.md

@@ -18,7 +18,7 @@ Read the specific rule files based on whether you are working on the Backend or
 - [backend/config.md](backend/config.md) - Configuration management and environment variables
 - [backend/controllers.md](backend/controllers.md) - Request handling and Class-Based Controllers
 - [backend/cron.md](backend/cron.md) - Scheduled background tasks and automation
-- [backend/database.md](backend/database.md) - Query Builder and DB best practices
+- [backend/database.md](backend/database.md) - Query Builder, Write-Behind Cache, and DB best practices
 - [backend/forms.md](backend/forms.md) - Form processing and Validation logic
 - [backend/ipc.md](backend/ipc.md) - Inter-Process Communication and state sharing
 - [backend/mail.md](backend/mail.md) - Transactional email sending

package/docs/ai/skills/backend/database.md

@@ -1,30 +1,32 @@
 ---
 name: backend-database-skill
-description: High-performance ODAC database querying patterns using the built-in query builder with secure and efficient data access.
+description: High-performance ODAC database querying patterns including the Write-Behind Cache for counters, last-write-wins updates, and buffered batch inserts.
 metadata:
-  tags: backend, database, query-builder, sql, indexing, performance, security
+  tags: backend, database, query-builder, sql, write-behind-cache, performance, security
 ---
 
 # Backend Database Skill
 
-High-performance database operations using the ODAC Query Builder.
+High-performance database operations using the ODAC Query Builder and Write-Behind Cache.
 
 ## Principles
 1.  **Directness**: Avoid ORM overhead. Use fluent Query Builder.
 2.  **Safety**: Always use parameterized queries (built-in).
 3.  **Efficiency**: Index foreign keys. No `SELECT *`.
+4.  **Write Coalescing**: Use `buffer` for high-frequency writes to avoid DB saturation.
 
-## Patterns
+## Query Builder Patterns
 ```javascript
-const user = await Odac.DB.table('users')
+const user = await Odac.DB.users
   .select('id', 'name', 'email')
   .where('status', 'active')
-  .first();
+  .first()
 
-await Odac.DB.table('posts').insert({
-  title: 'Hello',
-  user_id: 1
-});
+await Odac.DB.posts.insert({title: 'Hello', user_id: 1})
+
+await Odac.DB.users.where('id', 1).update({last_login: new Date()})
+
+const count = await Odac.DB.users.where('active', true).count() // → Number
 ```
 
 ## ID Strategy (NanoID)
@@ -43,7 +45,96 @@ module.exports = {
 }
 
 // ID is generated automatically
-await Odac.DB.table('posts').insert({title: 'Hello'});
+await Odac.DB.posts.insert({title: 'Hello'})
+```
+
+## Write-Behind Cache (`buffer`)
+
+The `buffer` API routes all writes through `Odac.Ipc`. The active IPC driver determines the scaling model — no code changes required when switching drivers.
+
+- **`memory` driver** (default): Primary process holds all state; workers communicate via cluster IPC.
+- **`redis` driver**: State lives in Redis — works transparently across multiple servers.
+
+### When to suggest `buffer`
+
+Propose the Write-Behind Cache when the user's write operation meets **all three** of these criteria:
+1. **High frequency** — the same column or row is written on many requests (counters, timestamps, last-seen values).
+2. **Eventual consistency is acceptable** — a few seconds' delay before the value reaches the DB is fine.
+3. **Not safety-critical** — losing the buffered value in a crash has no financial, legal, or user-facing consequence.
+
+**Typical candidates:**
+- Page / post / download view counters (`increment`)
+- Like, upvote, share counts (`increment`)
+- User last-active timestamp, last IP (`update`)
+- Analytics events, audit logs, activity streams (`insert`)
+- Score accumulators, play counts, rating tallies (`increment`)
+
+**Do NOT suggest `buffer` for:**
+- Payments, charges, refunds, or any monetary operation
+- Order creation, inventory decrements
+- Anything the same request needs to read back immediately
+- Inserts that return a generated ID the caller uses
+
+When in doubt, use a direct DB call.
+
+**Three operation types:**
+
+### 1. Counter Increment (Write Coalescing)
+Accumulates deltas — multiple increments merge into one `UPDATE col = col + delta`.
+`get()` returns `base + pending delta` (always current, no DB read needed).
+```javascript
+// Increment — returns current total (DB base + buffered delta)
+const views = await Odac.DB.posts.buffer.where(postId).increment('views')
+const likes = await Odac.DB.posts.buffer.where(postId).increment('likes', 5)
+
+// Read buffered counter (no extra DB round-trip)
+const current = await Odac.DB.posts.buffer.where(postId).get('views')
+
+// Composite key
+await Odac.DB.post_stats.buffer.where({post_id: 1, date: '2026-04-01'}).increment('views')
+```
+
+### 2. Last-Write-Wins Update (Field Coalescing)
+Multiple updates to the same row merge column maps — 50 requests = 1 `UPDATE` at flush.
+```javascript
+// Columns are merged per row: first update + second update = single UPDATE at flush
+await Odac.DB.users.buffer.where(userId).update({active_date: new Date()})
+await Odac.DB.users.buffer.where(userId).update({last_ip: req.ip})
+// → UPDATE users SET active_date = ?, last_ip = ? WHERE id = ?  (one query)
+```
+
+### 3. Batch Insert (Queue)
+Rows accumulate in memory; flushed in chunks of 1000. Auto-flushes when `maxQueueSize` is reached.
+```javascript
+await Odac.DB.activity_log.buffer.insert({user_id: userId, action: 'page_view', meta: url})
+```
+
+### Manual Flush
+```javascript
+await Odac.DB.posts.buffer.flush()   // flush this table only
+await Odac.DB.buffer.flush()         // flush everything
+```
+
+## Write-Behind Cache — Key Rules
+1.  **Ipc-Backed**: All buffer state goes through `Odac.Ipc`. Memory driver = Primary holds state; Redis driver = Redis holds state.
+2.  **Horizontally Scalable**: With Redis driver, multiple servers share the same buffer state. Distributed lock (`Ipc.lock`) prevents duplicate flushes.
+3.  **Crash-Safe (memory)**: LMDB checkpoint written every 30s. On restart, pending data is recovered and flushed before serving traffic.
+4.  **Crash-Safe (redis)**: Redis persistence provides durability. LMDB checkpoints are skipped.
+5.  **get() is authoritative**: Always returns `DB base + buffered delta`. Never stale.
+6.  **Flush on shutdown**: `Database.close()` triggers a final flush automatically — no data loss on graceful shutdown.
+7.  **Error resilience**: If a flush fails, data is retained in Ipc for the next cycle. Never lost silently.
+8.  **NEVER use buffer for safety-critical writes**: Payment records, order confirmations, balance changes, inventory decrements — anything where data loss has real-world consequences MUST use direct DB transactions. The buffer does not guarantee delivery before a crash.
+
+## Configuration (`odac.json`)
+```json
+{
+  "buffer": {
+    "flushInterval": 5000,
+    "checkpointInterval": 30000,
+    "maxQueueSize": 10000,
+    "primaryKey": "id"
+  }
+}
 ```
 
 ## Migration Awareness
@@ -53,4 +144,4 @@ await Odac.DB.table('posts').insert({title: 'Hello'});
 4.  **Indexes**: Keep index definitions in schema so add/drop is managed automatically.
 5.  **Data Changes**: Use `migration/*.js` only for one-time data transformation.
 
-See: [migrations.md](./migrations.md)
+See: [migrations.md](./migrations.md) | [write-behind-cache user docs](../../../backend/08-database/05-write-behind-cache.md)

package/docs/ai/skills/backend/ipc.md

@@ -24,25 +24,81 @@ IPC abstracts the underlying driver, allowing seamless transition between `memor
 ### 1. Key-Value Storage
 ```javascript
 // Set value with optional TTL (seconds)
-await Odac.Ipc.set('maintenance_mode', true);
-await Odac.Ipc.set('cache_key', { data: 123 }, 60);
+await Odac.Ipc.set('maintenance_mode', true)
+await Odac.Ipc.set('cache_key', {data: 123}, 60)
 
 // Get value
-const status = await Odac.Ipc.get('maintenance_mode');
+const status = await Odac.Ipc.get('maintenance_mode')
 
 // Delete value
-await Odac.Ipc.del('maintenance_mode');
+await Odac.Ipc.del('maintenance_mode')
 ```
 
-### 2. Pub/Sub Messaging
+### 2. Atomic Counters
 ```javascript
-// Subscribe to a channel (usually in a service or app start)
+// Increment / decrement a numeric key (returns new value)
+await Odac.Ipc.incrBy('page:views', 1)    // → 1
+await Odac.Ipc.incrBy('page:views', 5)    // → 6
+await Odac.Ipc.decrBy('page:views', 2)    // → 4
+
+// Read current value
+const views = await Odac.Ipc.get('page:views')  // → 4
+```
+
+### 3. Hash Maps
+```javascript
+// Set / merge fields (last-write-wins per field)
+await Odac.Ipc.hset('user:1', {active_date: new Date(), last_ip: '1.2.3.4'})
+await Odac.Ipc.hset('user:1', {score: 42})
+
+// Get all fields
+const fields = await Odac.Ipc.hgetall('user:1')
+// → {active_date: ..., last_ip: '1.2.3.4', score: 42}
+```
+
+### 4. Lists
+```javascript
+// Append items to the right (returns new length)
+await Odac.Ipc.rpush('events', {type: 'click'}, {type: 'view'})  // → 2
+
+// Read range (inclusive, -1 = last item)
+const items = await Odac.Ipc.lrange('events', 0, -1)
+```
+
+### 5. Sets
+```javascript
+// Add members
+await Odac.Ipc.sadd('online_users', 'user:1', 'user:2')
+
+// Get all members
+const users = await Odac.Ipc.smembers('online_users')  // → ['user:1', 'user:2']
+
+// Remove members (returns removed count)
+await Odac.Ipc.srem('online_users', 'user:1')
+```
+
+### 6. Distributed Locks
+```javascript
+// Acquire lock with TTL in seconds (returns true if acquired, false if already held)
+const acquired = await Odac.Ipc.lock('flush:lock', 10)
+if (!acquired) return  // another process is holding the lock
+
+try {
+  // ... critical section ...
+} finally {
+  await Odac.Ipc.unlock('flush:lock')
+}
+```
+
+### 7. Pub/Sub Messaging
+```javascript
+// Subscribe to a channel
 await Odac.Ipc.subscribe('notifications', (msg) => {
-  console.log('Received:', msg);
-});
+  console.log('Received:', msg)
+})
 
 // Publish a message from any worker
-await Odac.Ipc.publish('notifications', { type: 'alert', text: 'System update' });
+await Odac.Ipc.publish('notifications', {type: 'alert', text: 'System update'})
 ```
 
 ## Configuration
@@ -57,6 +113,9 @@ In `odac.json` or a config provider:
 ```
 
 ## Best Practices
--   **Async First**: All IPC operations are asynchronous.
--   **TTL Usage**: Always set a TTL for temporary cache data to prevent memory bloat.
--   **Scaling**: Switch to `redis` driver when deploying across multiple containers or servers.
+- **Async First**: All IPC operations are asynchronous.
+- **TTL Usage**: Always set a TTL for temporary cache data to prevent memory bloat.
+- **Scaling**: Switch to `redis` driver when deploying across multiple containers or servers. No application code changes required.
+- **Locks**: Always release locks in a `finally` block to prevent deadlocks.
+- **Sets for indexes**: Use `sadd/smembers/srem` to track active keys — avoids expensive SCAN operations.
+- **Atomic counters over get+set**: Use `incrBy`/`decrBy` instead of `get` → compute → `set` to prevent race conditions.

package/docs/backend/08-database/05-write-behind-cache.md

@@ -0,0 +1,230 @@
+# Write-Behind Cache
+
+At high traffic, individual database writes for common operations — like incrementing a page view counter or stamping a user's last-active date — quickly saturate your connection pool. One million page views = one million `UPDATE` queries.
+
+ODAC's **Write-Behind Cache** solves this by buffering writes in memory and flushing them to the database in efficient batches. The only change to your code is adding `.buffer` to the chain.
+
+```javascript
+// Without buffer — 1 DB write per request
+await Odac.DB.posts.where(postId).update({views: Odac.DB.raw('views + 1')})
+
+// With buffer — 1 DB write per flush interval, for all requests combined
+await Odac.DB.posts.buffer.where(postId).increment('views')
+```
+
+---
+
+## How It Works
+
+**Architecture: Ipc-Backed, Driver-Agnostic**
+
+All buffered state is held in `Odac.Ipc`. The active IPC driver determines the scaling model:
+
+| Driver | Scope | When to use |
+|---|---|---|
+| `memory` (default) | Single machine — cluster workers share state via Primary process | Single-server deployments |
+| `redis` | Multi-machine — all servers share state in Redis | Horizontal scaling behind a load balancer |
+
+```
+// Memory driver (default)
+Worker 1 ─┐
+Worker 2 ─┼──→ Primary (Ipc memory store) ──→ DB (batch flush every 5s)
+Worker N ─┘
+
+// Redis driver
+Server A ─┐
+Server B ─┼──→ Redis (Ipc state) ──→ DB (flush — distributed lock prevents duplicate writes)
+Server C ─┘
+```
+
+A **distributed lock** (`Ipc.lock`) guarantees that only one process or server flushes at a time, even across multiple machines.
+
+**Crash Safety via LMDB Checkpoint** *(memory driver only)*
+
+Every 30 seconds, pending buffer data is written to the local LMDB store. On a crash and restart, ODAC recovers this checkpoint and flushes it to the database before accepting any traffic. When using the Redis driver, Redis itself provides durability — LMDB checkpoints are skipped.
+
+---
+
+## Three Operations
+
+### 1. Counter Increment
+
+Accumulates numeric deltas. Multiple increments to the same column merge into a single `UPDATE col = col + delta` at flush time.
+
+```javascript
+// Increment by 1 (default)
+await Odac.DB.posts.buffer.where(postId).increment('views')
+
+// Increment by a custom amount
+await Odac.DB.posts.buffer.where(postId).increment('likes', 5)
+await Odac.DB.downloads.buffer.where(fileId).increment('count', 3)
+```
+
+**Read the current value** — returns `DB base + pending delta`, always accurate:
+
+```javascript
+const currentViews = await Odac.DB.posts.buffer.where(postId).get('views')
+// → 4527 (e.g., 4500 in DB + 27 buffered, not yet flushed)
+```
+
+**Composite primary key:**
+
+```javascript
+await Odac.DB.post_stats.buffer
+  .where({post_id: 123, date: '2026-04-01'})
+  .increment('views')
+```
+
+---
+
+### 2. Last-Write-Wins Update
+
+Buffers column SET operations for a row. If the same row is updated multiple times before a flush, the values are merged — the latest value for each column wins. The entire pending set for a row is written in a single `UPDATE` at flush.
+
+```javascript
+// 50 requests update the same user → 1 UPDATE at flush
+await Odac.DB.users.buffer.where(userId).update({active_date: new Date()})
+await Odac.DB.users.buffer.where(userId).update({last_ip: req.ip})
+// → UPDATE users SET active_date = ?, last_ip = ? WHERE id = ?  (one query for all 50 requests)
+```
+
+**Composite primary key:**
+
+```javascript
+await Odac.DB.user_prefs.buffer
+  .where({user_id: 1, pref_key: 'theme'})
+  .update({pref_value: 'dark'})
+```
+
+**Combine with increment** — both flush in the same cycle:
+
+```javascript
+await Odac.DB.users.buffer.where(userId).increment('login_count')
+await Odac.DB.users.buffer.where(userId).update({active_date: new Date(), last_ip: req.ip})
+```
+
+---
+
+### 3. Batch Insert
+
+Queues rows in memory and inserts them in chunks of 1,000 at flush time. Ideal for audit logs, analytics events, and activity streams where individual inserts are wasteful.
+
+```javascript
+await Odac.DB.activity_log.buffer.insert({
+  user_id: userId,
+  action: 'page_view',
+  meta: req.url,
+  created_at: Date.now()
+})
+```
+
+The queue auto-flushes immediately if it exceeds `maxQueueSize` (default: 10,000 rows).
+
+---
+
+## Manual Flush
+
+Force an immediate flush for a specific table or for all buffered tables:
+
+```javascript
+// Flush a single table
+await Odac.DB.posts.buffer.flush()
+
+// Flush all buffered tables across all connections
+await Odac.DB.buffer.flush()
+```
+
+> Graceful shutdown (`SIGTERM`/`SIGINT`) triggers a final flush automatically before the DB connections are closed. You do not need to call `flush()` in your shutdown handlers.
+
+---
+
+## Configuration
+
+Add a `buffer` section to your `odac.json`:
+
+```json
+{
+  "buffer": {
+    "flushInterval": 5000,
+    "checkpointInterval": 30000,
+    "maxQueueSize": 10000,
+    "primaryKey": "id"
+  }
+}
+```
+
+| Option | Default | Description |
+|---|---|---|
+| `flushInterval` | `5000` | How often (ms) to flush pending data to the database |
+| `checkpointInterval` | `30000` | How often (ms) to write a crash-recovery checkpoint to LMDB *(memory driver only)* |
+| `maxQueueSize` | `10000` | Auto-flush the insert queue when it reaches this many rows |
+| `primaryKey` | `"id"` | Default primary key column name for scalar `where()` values |
+
+---
+
+## Horizontal Scaling
+
+To share buffer state across multiple servers, switch the `ipc` driver to `redis`:
+
+```json
+{
+  "ipc": {
+    "driver": "redis",
+    "redis": "default"
+  }
+}
+```
+
+With the Redis driver active:
+- All `increment`, `update`, and `insert` operations go to Redis atomically.
+- Any server can trigger a `flush()` — the distributed lock ensures no server writes twice.
+- LMDB checkpoints are skipped (Redis persistence provides the durability guarantee).
+
+No code changes are required in your application. The `.buffer` API is identical regardless of driver.
+
+---
+
+## Named Database Connections
+
+The buffer respects your multi-connection configuration. Access it via the named connection, then the table:
+
+```javascript
+// Default connection
+await Odac.DB.posts.buffer.where(postId).increment('views')
+
+// Named connection: 'analytics'
+await Odac.DB.analytics.events.buffer.insert({type: 'click', target: '#cta'})
+```
+
+---
+
+## Guarantees
+
+| Scenario | Behaviour |
+|---|---|
+| Worker crash | No data loss — all state is in the Primary process (memory) or Redis |
+| Primary crash | Pending data recovered from LMDB checkpoint on next startup *(memory driver)* |
+| Server crash (Redis) | Pending data is durable in Redis — recovered on next flush cycle |
+| DB flush error | Data is retained in Ipc and retried on the next flush cycle |
+| Graceful shutdown | Automatic final flush before connections close |
+| `get()` after `increment()` | Returns base + buffered delta — always accurate, no extra DB read |
+| Concurrent workers | Primary serializes all writes (memory) or Redis atomic ops prevent races |
+| Multiple servers | Distributed lock guarantees exactly one flush at a time |
+
+---
+
+## When to Use (and Not Use)
+
+**Use Write-Behind Cache for:**
+- Page/post view counters
+- Download counters, like/upvote counts
+- User last-active timestamps, last IP
+- Activity logs, analytics events, audit trails
+- Any write that is not immediately safety-critical and occurs on every request
+
+**Do not use for:**
+- Operations where the write must be visible to the *same* request that triggered it
+- Inserts that return generated IDs you need immediately (use direct `insert()`)
+
+> [!WARNING]
+> **Never use Write-Behind Cache for financial or safety-critical operations** — payment records, order confirmations, balance changes, inventory decrements, or any write where data loss or a delayed flush would have real-world consequences. The buffer does not guarantee that data reaches the database before a crash. Use direct database transactions for anything that matters immediately.

package/docs/backend/13-utilities/02-ipc.md

@@ -71,3 +71,120 @@ await Odac.Ipc.publish('chat:global', { user: 'Emre', text: 'Hello World' });
 
 > [!TIP]
 > When using `memory` driver, the subscription listener is registered in the current worker. When a message is published, it goes to the Main process and is then broadcasted to all subscribed workers.
+
+### Atomic Counters
+
+Use `incrBy` / `decrBy` to atomically increment or decrement a numeric key. These are safe to call from multiple workers simultaneously — no read-then-write race conditions.
+
+```javascript
+// Increment by 1 — returns new value
+await Odac.Ipc.incrBy('page:views', 1)   // → 1
+await Odac.Ipc.incrBy('page:views', 5)   // → 6
+
+// Decrement
+await Odac.Ipc.decrBy('page:views', 2)   // → 4
+
+// Read the result
+const views = await Odac.Ipc.get('page:views')  // → 4
+```
+
+> [!NOTE]
+> Keys that don't exist yet are initialised to `0` before the operation.
+
+---
+
+### Hash Maps
+
+Store and retrieve structured per-key data. Fields are merged on every `hset` call — existing fields not mentioned in the call are preserved.
+
+```javascript
+// Set fields (merged, not overwritten)
+await Odac.Ipc.hset('user:42', {active_date: new Date(), last_ip: '1.2.3.4'})
+await Odac.Ipc.hset('user:42', {score: 100})
+
+// Retrieve all fields
+const data = await Odac.Ipc.hgetall('user:42')
+// → {active_date: ..., last_ip: '1.2.3.4', score: 100}
+```
+
+---
+
+### Lists
+
+Append items to a shared list and read them back in order. Useful for queues and event streams.
+
+```javascript
+// Append items to the right — returns new list length
+await Odac.Ipc.rpush('jobs', {type: 'email', to: 'a@b.com'})
+await Odac.Ipc.rpush('jobs', {type: 'sms'}, {type: 'push'})  // → 3
+
+// Read a range (0-indexed, -1 = last item)
+const pending = await Odac.Ipc.lrange('jobs', 0, -1)
+```
+
+---
+
+### Sets
+
+Maintain a collection of unique string members.
+
+```javascript
+// Add members
+await Odac.Ipc.sadd('online', 'user:1', 'user:2', 'user:3')
+
+// List all members
+const online = await Odac.Ipc.smembers('online')  // → ['user:1', 'user:2', 'user:3']
+
+// Remove members — returns number of members actually removed
+await Odac.Ipc.srem('online', 'user:2')
+```
+
+---
+
+### Distributed Locks
+
+Acquire a mutex across all workers and servers before entering a critical section. The TTL prevents deadlocks if a process crashes while holding the lock.
+
+```javascript
+// Attempt to acquire the lock (TTL in seconds)
+const acquired = await Odac.Ipc.lock('report:generate', 30)
+
+if (!acquired) {
+  // Another process is already running this — skip
+  return
+}
+
+try {
+  // Critical section — only one process runs this at a time
+  await generateReport()
+} finally {
+  // Always release, even on error
+  await Odac.Ipc.unlock('report:generate')
+}
+```
+
+> [!TIP]
+> With the `redis` driver, locks work across multiple servers — making them true distributed locks.
+
+---
+
+## Method Reference
+
+| Method | Description |
+|---|---|
+| `set(key, value, ttl?)` | Store a value, with optional TTL in seconds |
+| `get(key)` | Retrieve a value |
+| `del(key)` | Delete a key |
+| `incrBy(key, delta)` | Atomically increment a numeric key |
+| `decrBy(key, delta)` | Atomically decrement a numeric key |
+| `hset(key, fields)` | Merge fields into a hash map |
+| `hgetall(key)` | Retrieve all fields of a hash map |
+| `rpush(key, ...items)` | Append items to a list |
+| `lrange(key, start, stop)` | Read a range of list items |
+| `sadd(key, ...members)` | Add members to a set |
+| `smembers(key)` | Get all members of a set |
+| `srem(key, ...members)` | Remove members from a set |
+| `lock(key, ttl)` | Acquire a mutex lock |
+| `unlock(key)` | Release a mutex lock |
+| `subscribe(channel, handler)` | Subscribe to a Pub/Sub channel |
+| `publish(channel, message)` | Publish a message to a channel |

package/package.json

@@ -7,7 +7,7 @@
     "email": "mail@emre.red",
     "url": "https://emre.red"
   },
-  "version": "1.4.7",
+  "version": "1.4.8",
   "license": "MIT",
   "engines": {
     "node": ">=18.0.0"