jsonbadger 0.5.0 → 0.6.0

package/src/sql/run.js

@@ -0,0 +1,46 @@
+/*
+ * MODULE RESPONSIBILITY
+ * Execute SQL text against the resolved connection and normalize query failures.
+ */
+import debug_logger from '#src/debug/debug-logger.js';
+import QueryError from '#src/errors/query-error.js';
+import {assert_condition} from '#src/utils/assert.js';
+import {is_function} from '#src/utils/value.js';
+
+async function run(sql_text, sql_params, connection) {
+	const params = sql_params || [];
+	const debug_mode = resolve_debug_mode(connection);
+	const pool_instance = resolve_pool_instance(connection);
+
+	debug_logger(debug_mode, 'sql_query', {
+		sql_text: sql_text,
+		params: params
+	});
+
+	try {
+		return await pool_instance.query(sql_text, params);
+	} catch(error) {
+		debug_logger(debug_mode, 'sql_error', {
+			sql_text: sql_text,
+			params: params,
+			message: error.message
+		});
+
+		throw new QueryError('SQL execution failed', {
+			sql_text: sql_text,
+			params: params,
+			cause: error.message
+		});
+	}
+}
+
+function resolve_pool_instance(connection) {
+	assert_condition(connection && is_function(connection.pool_instance?.query), 'run requires connection.pool_instance');
+	return connection.pool_instance;
+}
+
+function resolve_debug_mode(connection) {
+	return connection?.options?.debug === true;
+}
+
+export default run;

package/src/sql/write/build-delete-query.js

@@ -0,0 +1,33 @@
+/*
+ * MODULE RESPONSIBILITY
+ * Build SQL text and parameters for delete writes.
+ */
+/**
+ * Build one compiled delete query payload.
+ *
+ * @param {object} query_context
+ * @param {string} query_context.table_identifier
+ * @param {string} query_context.data_identifier
+ * @param {object} query_context.where_result
+ * @param {string} query_context.where_result.sql
+ * @param {Array<*>} query_context.where_result.params
+ * @returns {{sql_text: string, sql_params: Array<*>}}
+ */
+function build_delete_query(query_context) {
+	const sql_text =
+		`WITH target_row AS (SELECT id FROM ${query_context.table_identifier} WHERE ${query_context.where_result.sql} LIMIT 1) ` +
+		`DELETE FROM ${query_context.table_identifier} AS target_table ` +
+		`USING target_row ` +
+		`WHERE target_table.id = target_row.id ` +
+		`RETURNING target_table.id::text AS id, ` +
+		`target_table.${query_context.data_identifier} AS data, ` +
+		`target_table.created_at AS created_at, ` +
+		`target_table.updated_at AS updated_at`;
+
+	return {
+		sql_text,
+		sql_params: query_context.where_result.params
+	};
+}
+
+export default build_delete_query;

package/src/sql/write/build-insert-query.js

@@ -0,0 +1,42 @@
+/*
+ * MODULE RESPONSIBILITY
+ * Build SQL text and parameters for insert writes.
+ */
+import {jsonb_stringify} from '#src/utils/json.js';
+
+/**
+ * Build one insert query payload for a model row insert.
+ *
+ * @param {object} query_context
+ * @param {string} query_context.table_identifier
+ * @param {string} query_context.data_identifier
+ * @param {object} query_context.payload
+ * @param {object} query_context.base_fields
+ * @returns {object}
+ */
+function build_insert_query(query_context) {
+	const sql_columns = [query_context.data_identifier];
+	const sql_params = [jsonb_stringify(query_context.payload)];
+	const sql_values = ['$1::jsonb'];
+
+	if(query_context.base_fields.id !== undefined && query_context.base_fields.id !== null) {
+		sql_columns.push('id');
+		sql_params.push(String(query_context.base_fields.id));
+		sql_values.push('$' + sql_params.length + '::uuid');
+	}
+
+	for(const key of ['created_at', 'updated_at']) {
+		sql_columns.push(key);
+		sql_params.push(query_context.base_fields[key]);
+		sql_values.push('$' + sql_params.length + '::timestamptz');
+	}
+
+	return {
+		sql_text:
+			`INSERT INTO ${query_context.table_identifier} (${sql_columns.join(', ')}) VALUES (${sql_values.join(', ')}) ` +
+			`RETURNING id::text AS id, ${query_context.data_identifier} AS data, created_at AS created_at, updated_at AS updated_at`,
+		sql_params
+	};
+}
+
+export default build_insert_query;

package/src/sql/write/build-update-query.js

@@ -0,0 +1,65 @@
+/*
+ * MODULE RESPONSIBILITY
+ * Build SQL text and parameters for update writes.
+ */
+import {bind_parameter} from '#src/sql/parameter-binder.js';
+import {has_own} from '#src/utils/object.js';
+
+/**
+ * Build one compiled update query payload.
+ *
+ * @param {object} query_context
+ * @param {string} query_context.table_identifier
+ * @param {string} query_context.data_identifier
+ * @param {object} query_context.update_expression
+ * @param {object} query_context.update_expression.jsonb_ops
+ * @param {object} query_context.update_expression.timestamp_set
+ * @param {object} query_context.parameter_state
+ * @param {Array<*>} query_context.parameter_state.params
+ * @param {object} query_context.where_result
+ * @param {string} query_context.where_result.sql
+ * @param {Array<*>} query_context.where_result.params
+ * @returns {{sql_text: string, sql_params: Array<*>}}
+ */
+function build_update_query(query_context) {
+	const {data_identifier, update_expression, parameter_state, table_identifier, where_result} = query_context;
+
+	// Finalize the JSONB mutation expression.
+	// The SQL boundary owns JSONB compilation and should compile via
+	// `jsonb_ops.compile(parameter_state)` as the new contract lands.
+	const compiled_data_expression = update_expression.jsonb_ops.compile(parameter_state);
+
+	const assignments = [`${data_identifier} = ${compiled_data_expression}`];
+	const timestamps = update_expression.timestamp_set;
+	const params = parameter_state;
+
+	if(has_own(timestamps, 'created_at')) {
+		const created_at_param = bind_parameter(params, timestamps.created_at);
+		assignments.push(`created_at = ${created_at_param}::timestamptz`);
+	}
+
+	if(has_own(timestamps, 'updated_at')) {
+		const updated_at_param = bind_parameter(params, timestamps.updated_at);
+		assignments.push(`updated_at = ${updated_at_param}::timestamptz`);
+	}
+
+	const sql_text =
+		`WITH target_row AS (SELECT id FROM ${table_identifier} WHERE ${where_result.sql} LIMIT 1) ` +
+		`UPDATE ${table_identifier} AS target_table ` +
+		`SET ${assignments.join(', ')} ` +
+		`FROM target_row ` +
+		`WHERE target_table.id = target_row.id ` +
+		`RETURNING target_table.id::text AS id, ` +
+		`target_table.${data_identifier} AS data, ` +
+		`target_table.created_at AS created_at, ` +
+		`target_table.updated_at AS updated_at`;
+
+	const sql_params = [...where_result.params, ...parameter_state.params];
+
+	return {
+		sql_text,
+		sql_params
+	};
+}
+
+export default build_update_query;

package/src/utils/assert.js

@@ -1,27 +1,34 @@
-const identifier_pattern = /^[a-zA-Z_][a-zA-Z0-9_]*$/;
-const path_pattern = /^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)*$/;
-
-export function assert_condition(condition_value, message) {
-	if(!condition_value) {
-		throw new Error(message || 'Assertion failed');
-	}
-}
-
-export function assert_identifier(identifier_value, label) {
-	const label_value = label || 'identifier';
-
-	assert_condition(typeof identifier_value === 'string', label_value + ' must be a string');
-	assert_condition(identifier_pattern.test(identifier_value), label_value + ' has invalid characters');
-}
-
-export function assert_path(path_value, label) {
-	const label_value = label || 'path';
-
-	assert_condition(typeof path_value === 'string', label_value + ' must be a string');
-	assert_condition(path_pattern.test(path_value), label_value + ' has invalid characters');
-}
-
-export function quote_identifier(identifier_value) {
-	assert_identifier(identifier_value, 'identifier');
-	return '"' + identifier_value + '"';
-}
+const identifier_pattern = /^[a-zA-Z_][a-zA-Z0-9_]*$/;
+const path_pattern = /^[a-zA-Z_][a-zA-Z0-9_]*(\.[a-zA-Z_][a-zA-Z0-9_]*)*$/;
+
+function assert_condition(condition_value, message) {
+	if(!condition_value) {
+		throw new Error(message || 'Assertion failed');
+	}
+}
+
+function assert_identifier(identifier_value, label) {
+	const label_value = label || 'identifier';
+
+	assert_condition(typeof identifier_value === 'string', label_value + ' must be a string');
+	assert_condition(identifier_pattern.test(identifier_value), label_value + ' has invalid characters');
+}
+
+function assert_path(path_value, label) {
+	const label_value = label || 'path';
+
+	assert_condition(typeof path_value === 'string', label_value + ' must be a string');
+	assert_condition(path_pattern.test(path_value), label_value + ' has invalid characters');
+}
+
+function quote_identifier(identifier_value) {
+	assert_identifier(identifier_value, 'identifier');
+	return '"' + identifier_value + '"';
+}
+
+export {
+	assert_condition,
+	assert_identifier,
+	assert_path,
+	quote_identifier
+};

package/src/utils/delta-tracker/.archive/1 tracker-redesign-codex-v2.md

@@ -0,0 +1,250 @@
+## Cleaner Redesign For JSONB Updates
+
+```js
+const document = DirtyTracker(new Document(row), {track: ['data']});
+
+document.data.preferences.theme = 'dark';
+delete document.data.preferences.legacy_flag;
+
+await document.save();
+```
+
+The most efficient design is to stop deriving SQL updates from a dirty-path list after the fact. Instead, track a canonical change plan as mutations happen, then compile that plan directly into SQL.
+
+## Core Idea
+
+Build the system around one internal artifact:
+
+```js
+[
+	{kind: 'set', path: ['preferences', 'theme'], value: 'dark'},
+	{kind: 'unset', path: ['preferences', 'legacy_flag']},
+	{kind: 'replace_root', value: {...}}
+]
+```
+
+Do not make `model.js` rediscover intent from snapshots and dirty strings. Let the tracker produce normalized operations up front.
+
+Because the tracker is initialized as `DirtyTracker(document, {track: ['data']})`, this change list should describe only mutations relative to the tracked branch. In the model layer, those changes map to `document.data`. Base fields like `id`, `created_at`, and `updated_at` still belong to the outer model and SQL update flow.
+
+## Why This Is Better
+
+- No special-case guessing for `data` vs `data.foo.bar`.
+- No fake root replacement through `$set`.
+- No silent deletion drift.
+- No need to reconstruct lost intent from the current object graph.
+- The SQL layer receives exactly the operation type it needs to compile.
+
+## Recommended Architecture
+
+### 1. Keep `Document` plain
+
+`Document` should stay as the simple state holder and path utility surface.
+
+It should own:
+- `id`
+- `data`
+- `created_at`
+- `updated_at`
+- plain helpers like `get()`, `set()`, and maybe `unset()`
+
+It should not know PostgreSQL details.
+
+### 2. Replace “dirty fields” with semantic changes
+
+The tracker should maintain a change list instead of only a `dirty_keys` set.
+
+Suggested internal model:
+
+```js
+{
+	base_state: {...},
+	changes: [],
+	change_index: new Map(),
+	watchers: [],
+	proxy_cache: new WeakMap()
+}
+```
+
+The tracker API can still expose friendly helpers:
+
+```js
+document.$has_changes()
+document.$get_changes()
+document.$reset_changes()
+document.$rebase_changes()
+```
+
+`$get_dirty_fields()` can remain as a compatibility helper if needed, but it should become a derived view, not the source of truth.
+
+### 3. Track semantic operations, not just paths
+
+When the tracked branch changes, record operations like:
+
+- `set(path, value)`
+- `unset(path)`
+- `replace_root(value)`
+
+This removes ambiguity.
+
+Examples:
+
+```js
+document.data.profile.age = 31;
+// => {kind: 'set', path: ['profile', 'age'], value: 31}
+
+delete document.data.profile.age;
+// => {kind: 'unset', path: ['profile', 'age']}
+
+document.data = {profile: {age: 31}};
+// => {kind: 'replace_root', value: {profile: {age: 31}}}
+```
+
+### 4. Add `deleteProperty` support to the tracker
+
+Right now the tracker is focused on `get` and `set`. A proper JSONB sync story also needs `deleteProperty`.
+
+That is the clean place to capture leaf removal without inventing `undefined` semantics.
+
+### 5. Treat root replacement as a first-class operation
+
+Do not encode tracked-root replacement as:
+
+```js
+{$set: {...}}
+```
+
+That is not root replacement. It is only a collection of path assignments.
+
+Use a real operation:
+
+```js
+{kind: 'replace_root', value: next_value}
+```
+
+Then compile it directly to:
+
+```sql
+data = $1::jsonb
+```
+
+## SQL Compiler Design
+
+### 1. Compile from changes
+
+The PostgreSQL layer should accept normalized operations, not infer them from ad hoc object shapes.
+
+Suggested internal compiler contract:
+
+```js
+build_payload_update_expression(data_identifier, changes)
+```
+
+The payload compiler should only assemble the expression for the `.data` column. The outer update compiler can combine that with other assignments like `updated_at`.
+
+### 2. Supported operation mapping
+
+- `set(path, value)` -> `jsonb_set(...)`
+- `unset(path)` -> `#-`
+- `replace_root(value)` -> direct `data = $1::jsonb`
+
+Example:
+
+```js
+[
+	{kind: 'set', path: ['preferences', 'theme'], value: 'dark'},
+	{kind: 'unset', path: ['preferences', 'legacy_flag']}
+]
+```
+
+becomes roughly:
+
+```sql
+(jsonb_set(data, '{preferences,theme}', $1::jsonb, true) #- '{preferences,legacy_flag}')
+```
+
+### 3. Resolve conflicts before SQL compilation
+
+Do not let the SQL compiler guess which op wins.
+
+Normalize the operation list before compilation:
+
+- `replace_root` wipes earlier changes
+- last write wins for identical paths
+- parent/child conflicts collapse to the minimal valid form
+
+Example:
+
+```js
+set(profile, {...})
+set(profile.age, 31)
+```
+
+Normalize to one final operation set before SQL generation.
+
+## Suggested Rules
+
+### Payload rules
+
+- Track only `document.data` for JSONB persistence.
+- Keep base columns outside payload tracking.
+- Rebase after successful insert/hydrate/update.
+
+### Mutation rules
+
+- `set path` means JSONB set
+- `delete path` means JSONB unset
+- `assign document.data = ...` means payload root replacement
+- `assign undefined` should not silently mean delete
+
+### Array rules
+
+Keep arrays simple unless you truly need patch-level array semantics.
+
+Recommended default:
+- replacing an array records one `set` on that array path
+- mutating arrays in place can also collapse to one parent-array `set`
+- add explicit array operators later only if needed
+
+That avoids a lot of fragile path math and still gives efficient updates for normal usage.
+
+## Clean Save Flow
+
+```js
+async function save_model(model_instance) {
+	const document = model_instance.document;
+	const changes = document.$get_changes();
+
+	if(!changes.length) {
+		return model_instance;
+	}
+
+	const data_expression = build_payload_update_expression('data', changes);
+	const updated_row = await exec_update_one(model, {id: document.id}, {data_expression});
+
+	document.init(updated_row);
+	document.$rebase_changes();
+
+	return model_instance;
+}
+```
+
+This is the key simplification:
+
+- `model.js` should orchestrate
+- the tracker should describe changes
+- the payload SQL builder should compile the `.data` update
+
+Each layer does one job.
+
+## Recommendation
+
+The most beautiful version is:
+
+- plain `Document`
+- tracker mounted at the document root with `track: ['data']`
+- tracker emits semantic change operations
+- SQL compiler consumes those changes for the `.data` column
+- no reverse-engineering of intent from dirty strings
+
+That design removes nearly all of the hacks around root replacement, deletions, and JSONB path edge cases because those cases stop being edge cases. They become normal operation types.

package/src/utils/delta-tracker/.archive/1 tracker-redesign-gemini.md

@@ -0,0 +1,101 @@
+Zooming out and redesigning this without constraints is exactly what this architecture needs right now. We’ve been trying to force a square peg (a rich, reactive proxy diff) into a round hole (a query builder that currently only understands simple `$set` root paths). 
+
+If we have the freedom to refactor upstream, we can eliminate all the string-stripping hacks, the `undefined` edge-case skipping, and the `extract_diff` middleman entirely.
+
+Here is what the "Holy Grail" architecture looks like for a reactive, JSONB-backed Postgres ORM.
+
+### 1. The Tracker Layer: Emit Deltas, Not Just Paths
+Right now, the tracker just keeps a `Set` of dirty strings (`['data.age', 'data.preferences']`). We are leaving too much semantic meaning on the table.
+
+**The Fix:** We refactor the Proxy to intercept `deleteProperty` as well as `set`. Instead of returning an array of strings, the tracker exposes a `$get_delta()` method that returns a structured patch ready for a NoSQL-style query builder.
+
+```javascript
+// What model.document.$get_delta() would return:
+{
+  $set: {
+    'preferences.theme': 'dark', // Native stripping of 'data.' done at the proxy config level
+    'age': 30
+  },
+  $unset: [
+    'obsolete_key' // Caught via the `delete` keyword or explicit undefined
+  ],
+  $replace_root: false // Flips to true if they did `model.data = { ... }`
+}
+```
+*No `extract_diff` required. The tracker naturally speaks the language of the database.*
+
+### 2. The Model Layer: The Clean Handoff
+In `model.js`, `Model.prototype.update` becomes incredibly thin and elegant. It just grabs the delta from the tracker and passes it straight into the update executor.
+
+```javascript
+Model.prototype.update = async function() {
+    if (!this.document.$has_dirty_fields()) return this;
+
+    const delta = this.document.$get_delta();
+
+    // If the developer replaced the entire object, bypass JSONB surgery
+    if (delta.$replace_root) {
+        await exec_update_one(model, { id: this.id }, { $replace: this.payload });
+    } else {
+        // Pass the surgical set/unset instructions directly
+        await exec_update_one(model, { id: this.id }, { $set: delta.$set, $unset: delta.$unset });
+    }
+
+    this.document.$rebase_dirty_fields();
+    return this;
+};
+```
+
+### 3. The Query Builder Layer: Chained JSONB SQL (The Magic)
+This is where the real power of Postgres comes in. We update `create-update-query.js` (and its expression compilers) to construct a **Chained JSONB Expression**. 
+
+Postgres allows you to nest `jsonb_set` and the deletion operator (`#-`) to apply multiple surgical changes to a JSON column in a single pass without overriding the whole column.
+
+If our delta is:
+`$set: { 'a.b': 1, 'c': 2 }`, `$unset: ['d.e']`
+
+The query compiler generates this SQL:
+```sql
+UPDATE table_name 
+SET 
+  data = jsonb_set(
+           jsonb_set(
+             data #- '{d,e}',    -- 1. Unset the deleted leaf first
+             '{a,b}', $1::jsonb  -- 2. Set the first new leaf
+           ),
+           '{c}', $2::jsonb      -- 3. Set the second new leaf
+         ),
+  updated_at = NOW()
+WHERE id = $3
+```
+
+**How we build this upstream (`create-update-query.js` context):**
+You start with the base column name as your expression string, and iteratively wrap it.
+```javascript
+let data_expr = 'data';
+
+// 1. Chain all unsets
+for (const path of unset_paths) {
+    const pg_path = format_pg_array(path); // 'd.e' -> '{d,e}'
+    data_expr = `${data_expr} #- '${pg_path}'`;
+}
+
+// 2. Chain all sets
+for (const [path, val] of Object.entries(set_payload)) {
+    const pg_path = format_pg_array(path); // 'a.b' -> '{a,b}'
+    const param_id = bind_parameter(params, val);
+    data_expr = `jsonb_set(${data_expr}, '${pg_path}', ${param_id}::jsonb)`;
+}
+
+// Resulting in a single clean assignment for the query builder:
+assignments.push(`data = ${data_expr}`);
+```
+
+### Why this approach is "Beautiful":
+1. **Zero Hacks:** We stop writing code to protect the query builder from things it can't do, and instead teach the query builder how to do them natively.
+2. **True State Synchronization:** If a frontend sends a payload missing a key, or a developer does `delete model.payload.feature_flag`, the database correctly executes a `#-` deletion instead of leaving stale data floating around in the JSONB column.
+3. **Perfect Encapsulation:** The tracker handles the "what changed" logic. The query builder handles the "how to write it to Postgres" logic. `model.js` just hands the baton between them.
+
+If we refactor towards this, we throw away `extract-diff.js` completely. We upgrade `instance.js` to expose `$get_delta()`, and we add a few lines to your update query helpers to support `$unset` and `$replace`. 
+
+Does this architectural direction feel like the kind of robust, scalable solution you are aiming for?

package/src/utils/delta-tracker/.archive/2 evaluation by gemini.txt

@@ -0,0 +1,65 @@
+This is a fascinating architectural pivot. Both proposals correctly identify the root flaw in the current `instance.js` implementation: trying to reverse-engineer database intent from a flattened `Set` of dirty string paths is a fragile anti-pattern. By moving the intent capture to the Proxy level, you completely eliminate the brittle parsing logic.
+
+Here is an evaluation of both approaches, breaking down their strengths, weaknesses, and how they interact with your current `DirtyTracker`.
+
+### Architectural Comparison
+
+| Feature | Codex V2 (Semantic Operations List) | Gemini (Mongo-style Delta Map) |
+| :--- | :--- | :--- |
+| **Data Structure** | Array of objects (`[{kind: 'set', ...}]`) | Grouped object (`{$set: {...}, $unset: [...]}`) |
+| **Mutation Tracking** | Chronological (records every change in order) | State-collapsed (last write wins natively via object keys) |
+| **Root Replacement** | Explicit operation: `{kind: 'replace_root', value: ...}` | Boolean flag: `$replace_root: true` (relies on outer state) |
+| **SQL Generation** | Requires a pre-compilation step to normalize conflicts | Direct mapping (iterate unsets, then iterate sets) |
+| **Proxy Implementation** | Heavier: Must append to array and manage path overlaps | Lighter: Just updates the `$set` or `$unset` object keys |
+
+---
+
+### Feature Ratings & Analysis
+
+**1. The Tracker API & State Construction**
+* **Winner: Gemini (Mongo-style Delta Map)**
+* **Why:** In the Codex approach, tracking every operation in an array means you have to write a complex "conflict resolution" algorithm before generating SQL. If a user sets `profile.age` to 30, then 31, then deletes `profile`, the Codex array has three entries that must be collapsed. The Gemini approach uses object keys, meaning state naturally collapses as it mutates. A later set simply overwrites the earlier key in the `$set` object.
+
+**2. SQL Compilation Pipeline**
+* **Winner: Gemini**
+* **Why:** Generating Postgres JSONB chaining is drastically simpler with a grouped delta. You can reliably execute all `$unset` operations first, followed by all `$set` operations. This ensures that a parent deletion doesn't accidentally wipe out a subsequent child insertion. The Codex array would require sorting or graph analysis to achieve this same safety guarantee.
+
+**3. Handling Root Replacements (`document.data = {...}`)**
+* **Winner: Codex V2**
+* **Why:** The Gemini proposal suggests `{ $replace_root: true }` and then relying on `this.payload` in the model to provide the data. This breaks the encapsulation of the tracker. The delta should be a pure, self-contained set of instructions. Codex handles this perfectly by making it a distinct operation that carries its own payload: `{ kind: 'replace_root', value: next_value }`.
+
+**4. Handling Deletions**
+* **Winner: Tie**
+* **Why:** Both proposals correctly identify that `instance.js` is missing a `deleteProperty` trap in the Proxy. Right now, `delete document.data.foo` circumvents the dirty tracker entirely. Both architectures require adding this trap to capture `$unset` operations.
+
+---
+
+### The Synthesized Architecture (The Best of Both)
+
+The ideal solution merges the clean NoSQL data structure of the Gemini proposal with the strict operational encapsulation of the Codex proposal. 
+
+By updating `instance.js`, you can modify the Proxy to output a normalized delta object directly, which the SQL builder can consume without any middleman logic.
+
+```javascript
+// The ideal output from document.$get_delta()
+{
+    replace_root: null, // or the complete new object
+    set: {
+        'preferences.theme': 'dark',
+        'profile.age': 31
+    },
+    unset: [
+        'preferences.legacy_flag'
+    ]
+}
+```
+
+**How this changes `instance.js`:**
+1.  **Add `deleteProperty`**: You must implement the `deleteProperty` trap in `build_proxy` to catch leaf removals and push them into an internal `store.unset_keys` Set.
+2.  **Intercept Object Assignment**: When `set` intercepts a write to the root tracked property (e.g., the entire `data` object is replaced), clear the `set` and `unset` trackers and assign the new object to `store.replace_root`.
+3.  **Cross-Cancellation**: If a key is added to `set`, remove it from `unset`. If a key is added to `unset`, remove it from `set`.
+
+**How this changes the SQL layer:**
+You pass this delta directly to the query builder. If `replace_root` has a value, compile a standard `data = $1::jsonb` query. Otherwise, loop through `unset` using the `#-` operator, then wrap that result by looping through `set` with `jsonb_set`.
+
+Would you like to draft the exact `deleteProperty` trap and delta-generation methods to slot into the `build_proxy` function of `instance.js`?