fix(relations,fixtures): ibis-sqlite null date/timestamp binding crash (item 112, IB-DT-19)

[discreteds]

Summary

Fixes item 112 — cross-backend test fixture factory crashes on null date/timestamp for ibis-sqlite — with scope expanded (see backlog doc, mountainash-central commit 425f6e7) to also cover mountainash's own production code, since the same crash is reachable independent of the original test-infra-only framing.

Root cause: ibis.backends.sqlite.Backend._register_in_memory_table always stages an in-memory table via a pandas roundtrip (op.data.to_frame()) before binding rows through stdlib sqlite3. A null date/timestamp value becomes pandas NaT, and sqlite3 has no adapter for NaTType — raises sqlite3.ProgrammingError before Mountainash's own visitor/compile machinery ever runs. Verified empirically (ibis 12.0.0) that explicit PyArrow schemas, ibis.memtable(schema=...), and object-dtype pandas columns all still crash — ibis re-normalises internally before the roundtrip regardless of input shape.

Fix: relations/backends/relation_systems/ibis/_sqlite_compat.py::ensure_sqlite_nat_adapter() — one idempotent, process-global sqlite3.register_adapter(NaTType, ...) call, invoked lazily wherever Mountainash builds an ibis.memtable()/create_table() from data that could contain a null temporal value:

• Production (new scope, found during implementation): relation_visitor.py's cross-type join coercion, relsys_ib_ext_ma_util.py's resource-ingestion fallback (2 call sites). These crash independent of whether mountainash-data ships its own DEBT-13 fix, since Mountainash builds ibis.memtable() directly, not through that layer.
• Test fixtures: the 4 duplicated ibis-sqlite table-creation call sites across backend_registry.py/backend_helpers.py/conftest.py now delegate to one shared helper instead of re-registering the workaround.

Rejected alternatives:

• pandas.DataFrame.to_sql() bypass avoids the crash but silently degrades Boolean columns to Int64 — an observable regression for every existing non-null fixture.
• Eager top-level adapter registration at package-import time — ibis-framework has no unconditional pandas dependency (only specific backend extras do), so this would regress every pandas-free ibis backend user.

Tests

• tests/fixtures/test_backend_registry.py, test_backend_helpers.py (new file): null date + null datetime regression fixture, parametrized over ALL_BACKENDS, for REGISTRY.build and BackendDataFrameFactory.create/create_pair.
• test_backend_registry.py::test_raw_ibis_sqlite_null_temporal_upstream_bug_ib_dt_19: xfail(strict=True) upstream-fix monitor — reproduces the raw crash in a subprocess isolated from Mountainash's own process-global adapter patch, so it flips to XPASS(strict) and fails CI the moment ibis fixes IB-DT-19 upstream.
• backend_helpers.py::get_count: fixed a pre-existing narwhals-lazy gap (missing .collect()) that blocked the new ALL_BACKENDS parametrization — unrelated to the main fix, found while writing the regression test.
• Manually verified the exact production scenario end-to-end (ma.relation(ibis_sqlite_table).join(polars_df_with_null_datetime)) before/after the fix.

Verification run

tests/fixtures/ + tests/relations/: 2685 passed, 11 skipped, 36 xfailed, 0 failed
ruff check: all checks passed (touched + new files)
mypy check: 9 pre-existing errors, unchanged — confirmed identical against develop baseline (none newly introduced)

Not in this PR

• mountainash-data's own DEBT-13 (IbisBackend.create_table, separate repo, separate write path) — explicitly out of scope, not shipped as of 2026-08-19.
• Filing the upstream ibis issue — drafted only (docs/upstream-issue-drafts/IB-DT-19-sqlite-nat-binding.md), per explicit instruction not to submit it.

Backlog

mountainash-central h.backlog/active/ibis-sqlite-fixture-factory-nat-crash.md updated (commit 425f6e7) to record the scope expansion and resolved fix shape.

🤖 Generated with assistance from an AI coding agent.