Skip to content
Fexl Lite

v1.6.98 — Postgres JE column gap

A targeted patch closing a gap between the SQLite (desktop) and Postgres (cloud) schemas. The codebase had assumed four columns existed on the journal-entries side for years; SQLite quietly added them in db/init.go’s PRAGMA-gated ALTER block, but the cloud equivalent never got them — the file-based PG migrations stopped at 005. v1.6.98 fixes the cloud side and backfills the historical data that landed in the gap.

Released 2 May 2026·Tag fexl-v1.6.98·1 migration · 1 sync-map fix

What shipped

  • fix PG migration 006 adds the four missing columns idempotently:

    • journal_entries.source_type
    • journal_entries.source_id
    • journal_entries.source_uuid
    • journal_entry_lines.account_code

    Plus two indexes for the source-linkage and account-code lookups that downstream handlers rely on.

  • fix Backfill account_code on existing JE-line rows from accounts.code via the account_id join, so historical entries match what the new posting path writes.

  • fix Sync FK map: journal_entries.source_id added to the polymorphic exclusion list (alongside the existing reference_id entry) so the FK resolver doesn’t try to remap a value that’s polymorphic by source_type rather than naming a single foreign table.

What was broken

On any cloud tenant before v1.6.98:

  • postJournalEntryWithDate INSERTs failed silently. The handler code references all four columns; PG rejected the INSERT with SQLSTATE 42703 (column does not exist). On at least one tenant, invoice 11905 — a completed sale — ended up with zero journal entries.
  • Cancel and return JE-source SELECTs errored with the same SQLSTATE, surfaced by v1.6.97’s swallowed-error fix.
  • Backfill migrations v23 / v25 / v26 / v27 / v28 / v35 that re-key by source linkage silently no-op’d on PG because the columns they updated didn’t exist.

Reports for affected periods on those tenants — P&L, Balance Sheet, Trial Balance, GL — were structurally wrong for any sale posted while the column gap was open.

Upgrading

Cloud tenants pick up the migration on next deploy. Desktop tenants are unaffected — SQLite already had the columns. No user action required either way.