Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 30 Oct 2026. What's built · Install 0.1.0
jadpo
Reference: Data

Data · rule

migration.backfill_outside_row

Computed backfill reads more than its row.

Area 5, Data; not declinable; the next step is usually the agent's.

A backfill reads only the record it fills:

example
migration {    Draft.starred: {        backfill: Note.starred    }}
text
error: The backfill for `Draft.starred` can't read `Note.starred` --> database/migrations/20261020T1401_add_starred/changes.jadpo:3:19  |3 |         backfill: Note.starred  |                   ^^^^^^^^^^^^ another entity's field  reason: A backfill works each `Draft` record's value out from that record's own fields, constants and pure functions, so it gives the same value whenever and wherever the migration runs.  next: Work the value out from `Draft`'s own fields, or a constant (agent)  rule: migration.backfill_outside_row  help: https://jadpo.dev/docs/errors/migration.backfill_outside_rowcheck failed: 1 error, 4 files

Nor does it read a setting through a function it calls, a crypto operation's key: included, since each deployment sets its own and jadpo migrate apply is given none:

example
use notes/types { Label }library draft_labels {    function default_label() -> Label {        return config.draft_label    }}
example
migration {    Draft.label: {        backfill: draft_labels.default_label()    }}
text
error: The backfill for `Draft.label` can't read `config.draft_label` --> database/migrations/20261020T1401_add_label/changes.jadpo:3:19  |3 |         backfill: draft_labels.default_label()  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ reads a setting, through `draft_labels.default_label`  reason: A backfill gives each `Draft` record the value its own fields give, whenever and wherever the migration runs, and `draft_labels.default_label` reads `config.draft_label`, which each deployment sets for itself.  next: Work the value out without `config.draft_label`: from `Draft`'s own fields, or a constant (agent)  rule: migration.backfill_outside_row  help: https://jadpo.dev/docs/errors/migration.backfill_outside_rowcheck failed: 1 error, 6 files

Nor a field the same migration adds, which no record already stored has a value for while the backfill runs:

example
migration {    Draft.title: {        backfill: "Untitled"    }    Draft.subheading: {        backfill: Draft.title    }}
text
error: The backfill for `Draft.subheading` can't read `Draft.title` --> database/migrations/20261020T1401_add_titles/changes.jadpo:6:19  |6 |         backfill: Draft.title  |                   ^^^^^^^^^^^ a field this migration adds  reason: `Draft.title` is added by this same migration, so no `Draft` record already stored has a value for it while the backfill runs.  next: Work the value out from the fields `Draft` had before this migration, or a constant (agent)  rule: migration.backfill_outside_row  help: https://jadpo.dev/docs/errors/migration.backfill_outside_rowcheck failed: 1 error, 4 files

Markdown for agents: /docs/errors/migration.backfill_outside_row.md.Built from Jadpo main at a707efb.