mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-22 02:23:46 +00:00
xarmian
7e37dfc34e
* refactor(store): drop defensive sql.NullString scans on collections.settings (IDEA-1484 follow-up) PR #562 (squash0766d7e) hardened collections.settings to NOT NULL DEFAULT '{}' at the schema level. The defensive sql.NullString scans introduced by PR #561 (BUG-1482, squash714da48) and the paired import-side ""→"{}" coercion in ImportWorkspace are no longer load-bearing — the database now enforces the invariant the readers were defensively reconstructing. Reverted sites: - internal/store/collections.go: GetCollection, ListCollectionsMinimal, ListCollections — direct &c.Settings scans. - internal/store/export.go: ExportWorkspace scan + ImportWorkspace coercion. - internal/store/items.go: scanCollectionDoneFilters helper. - internal/store/item_stars.go: buildCollectionDoneContextMap helper. Test changes: - Removed TestExportImportRoundTripWithEmptyStringSettings, whose purpose evaporated with the import-side coercion. The constraint-outcome tests (TestCollectionsSettingsNotNullEnforced, TestCollectionsSettingsDefaultsToEmptyObject) from PR #562 remain — they assert the load-bearing schema invariant. * fix(store): restore import-side settings coercion (codex R1 P1) Codex R1 caught that the prior commit reverted the import-side `""→"{}"` coercion incorrectly. The NOT NULL DEFAULT '{}' schema constraint added by PR #562 only fires when the INSERT omits the settings column — but ImportWorkspace explicitly supplies the value. A legacy bundle or external JSON workspace import whose `collections[].settings` is "" would therefore bypass the default: Postgres rejects "" at JSONB type-validation; SQLite silently stores invalid JSON. The coercion was doing two jobs (BUG-1482 had folded them together): 1. Defending against NULL-materialized-as-"" on read — obsolete now that the column cannot hold NULL. 2. Defending against legacy/external "" settings on the import boundary — still required because schema constraints don't validate JSON. Job #1's defense (the sql.NullString scans) stays reverted; the column cannot hold NULL. Job #2's defense (the import-side coercion) is restored and renamed in the comment to reflect that it's a boundary normalizer for external data, not a transitional NULL-handler. `TestExportImportRoundTripWithEmptyStringSettings` is restored with an updated comment that makes the boundary-normalization framing explicit. The constraint-outcome tests from PR #562 remain unchanged. Tests pass on both drivers (SQLite full ./..., Postgres internal/store + internal/server). * fix(store): coerce empty-string settings in UpdateCollection (codex R2 P2) Codex R2 surfaced UpdateCollection as the last writer path in the collections.settings contract that didn't enforce the JSON-validity invariant. A PATCH sending {"settings": ""} would write the empty string verbatim, bypassing the NOT NULL DEFAULT '{}' constraint (which only fires on column omission). Same failure mode as the ImportWorkspace bug R1 caught: Postgres rejects "" at JSONB type-validation, SQLite silently stores invalid JSON. Mirrors the boundary normalization restored in ImportWorkspace at6f22f94. Closes the contract loop for collections.settings — every writer path (CreateCollection via json marshalling, ImportWorkspace, UpdateCollection) now enforces JSON validity at the API boundary. Added TestUpdateCollectionCoercesEmptyStringSettings to guard the boundary. Also corrected a stale comment in TestCollectionsSettingsDefaultsToEmptyObject that referenced GetCollection's removed defensive scan. The sibling-table UPDATE paths (UpdateItem at items.go:1442, UpdateView at views.go:152) have the same defect class on items.fields/tags and views.config; they are pre-existing, not introduced by this PR, and are tracked in the sibling-table follow-up IDEA.