Notion dbops

/notion-dbops — lossless Notion bulk data-ops (merge OR purge)

The Notion MCP cannot delete an individual page/row directly (update-page has no in_trash; only whole data sources can be trashed). The workaround that makes both MERGE and PURGE safe and reversible is move-pages → in_trash, plus a reliable way to enumerate the rows. This skill codifies that. Apply memory feedback-data-safety-merges throughout: lose nothing, confirm the plan, migrate non-destructively, verify counts, delete recoverably.

Core primitives (both modes)

• Enumerate via the search drain-loop. notion-search with data_source_url is the only listing path and caps at 25 results (semantic, can miss). So: search (broad generic query) → act on that batch → search again (the acted-on rows are gone, new ones surface) → repeat until search returns empty. Never assume one search is complete.
• Identify the keep-set explicitly before any destructive move — by page-id (collect ids of rows to KEEP, e.g. the ones you just created have a distinct id prefix) or a marker property. Filter the keep-set OUT of every move batch.
• Move with notion-move-pages — up to 100 ids per call, new_parent = a data_source_id. Re-parenting is lossless (page body preserved); schema mismatch is fine.
• Trash with notion-update-data-source in_trash: true — sends the whole data source (and its rows) to Notion trash, recoverable 30 days.
• Verify survivors with notion-fetch on a keep-row id — the search index lags right after bulk moves and returns empty transiently, so fetch (by id) is the trustworthy check.

Mode A — PURGE (delete a row set)

Use when the user wants rows gone (e.g. "wipe all the old leads") but you must NOT touch the keep-set.

1. Confirm the plan + keep-set with the user (which rows die, which survive). Note they're recoverable for 30 days.
2. notion-create-database a throwaway bin DB (e.g. ZZZ-Trash-<topic>, minimal Name TITLE schema).
3. Drain-loop: search the source data source → collect ids → drop any keep-set ids → move-pages the rest into the bin's data_source_id → search again → repeat until empty.
4. notion-fetch one keep-row to confirm it's intact in the source DB.
5. notion-update-data-source in_trash: true on the bin data source. Done — only the moved rows are trashed; source DB id + inline embeds untouched.
6. Report: N purged, M kept, recoverable 30 days.

Mode B — MERGE (consolidate two DBs into one)

Use when two DBs should become one with zero record loss.

1. Probe both data sources for row counts + schemas. Pick the richer schema as canonical (the destination).
2. Reconcile schema deltas FIRST — especially text→select/multi_select: this API does NOT auto-create select options on a page update (it errors). ALTER the destination column to ADD every needed option (include all existing option names so current values are preserved) BEFORE moving.
3. move-pages all rows from the secondary into the canonical data source (drain-loop if >100; lossless, keeps page body).
4. Clean up the stray auto-created "<col> 1" column the move can create (DROP it after copying values if needed).
5. Verify counts: secondary = 0, canonical = original + moved. Use the drain-loop search to confirm the secondary is empty.
6. in_trash: true the emptied secondary data source (recoverable).
7. Report: counts before/after, options added, anything left for manual review.

Guardrails

• Confirm before trashing. Destructive + bulk → state the plan and the keep-set, get a yes, then act (it's reversible via trash but still confirm).
• Never trust a single search for completeness — drain to empty.
• Verify a survivor by fetch, not search (index lag).
• Bare orphan pages (not in a DB) still can't be trashed via MCP — surface those for the user's one-click manual delete.
• Do this in the main loop, not via parallel subagents (memory feedback-no-fanout-for-external-writes).