Seven from the issue sweep: #88, #84, #90, #92, #93, #97, and #17 cut

[jryannel]

Closes #88.
Closes #84.
Closes #90.
Closes #92.
Closes #93.
Closes #97.

The builder could say NULLS LAST and the REST sort grammar could not, so a resource whose natural ordering needs it had no way to get it. ?sort=-published_at compiled to a bare DESC, whose Postgres default is NULLS FIRST, and a feed ordered by a column that is NULL until a row is published lifted every draft to the top.

The direction

Declared on the column, which is the one the issue argued for:

schema.Timestamp("published_at").Nullable().Sortable(schema.NullsLast)

Where NULLs belong is a property of what the column means — a NULL published_at means "not published", which belongs last however the feed is sorted — not of what a caller wants. The grammar is untouched, so the generated TypeScript and Dart clients need no new syntax to get it right, and ?sort= stays one character of prefix.

It reuses the schema.Nulls the index orders already use (#64), so a resource sorted published_at DESC NULLS LAST and the index declared to serve it read as the pair they are. Description.SortNullsLast / SortNullsFirst are the hand-written-model half.

The placement applies in both directions. A rule that only bit on DESC would be a rule with an invisible exception, and the default it exists to escape is itself direction-following.

Two things that fell out

The cursor had to carry it. nullsAfter used to be a pure function of desc, so validating the direction validated the placement for free. It is not a pure function any more, so a cursor issued before a redeploy that changed a declaration would be interpreted under a placement it was not built for — silently wrong pages, the one failure keyset paging exists to prevent. cursorTerm now encodes the declared placement rather than the resolved one, which is what keeps it backward compatible: a column with no declaration encodes nothing, so cursors issued before the field existed still decode, while a column that gains one refuses them with the existing drop the cursor when the sort changes error.

restcompat had to see it. A placement change removes no parameter and rejects no request, so the capability diff is blind to it by construction — the sort key exists on both sides. It is now LevelBreaking on FacetSort: lists come back in a different order and outstanding cursors stop working. Same shape of gap as #68, one facet over.

Also carried into ColumnManifest.SortNulls, beside Capabilities rather than in it — a request can neither ask for it nor decline it.

Tests

• filter/sortnulls_test.go — both directions, the undeclared column still renders no NULLS clause, the grammar still refuses a spelling
• schema/sortnulls_test.go — tag round-trip, both panics, the manifest
• codegen/sortnulls_test.go — the declaration reaches the generated struct tag; without this the fix stops at the schema package
• cursor_nulls_test.go — the old-cursor and new-declaration cases in both directions
• restcompat/restcompat_test.go — the break, and that it is not reported as a capability delta

go test ./... and go vet ./... green. pgtest is a separate module and vets clean, but I could not run it — no Docker here — so the live-database half is unverified.

Not included

A resource still has no DefaultSort, so a caller must send ?sort= to get the ordering the resource was designed around. That was the issue's third direction and is separate work.

🤖 Generated with Claude Code

---

06d0c2f — an embedded date is the same shape as a direct one (#84)

Expanding a relation whose target had a date column answered 500: json_build_object serialises a date as "2026-07-01" and the Go field is a time.Time, which parses strictly as RFC 3339.

Fixed in the SQL rather than the decoder, because the issue's reason for not doing that turned out not to hold. A direct read of the same column scans through pgx into a time.Time and Go marshals it RFC 3339 — codegen/dartclient.go documents exactly this ("a date column does not arrive as YYYY-MM-DD, whatever the column type suggests") and the TS client types it string | Date. So the two representations already disagreed and the expansion held the side nothing expected; the cast removes an inconsistency rather than introducing one.

::timestamp AT TIME ZONE 'UTC', not ::timestamptz — the latter resolves through the session's TimeZone, so under Europe/Berlin the date would come back a day earlier. There is a test whose only job is to fail if someone shortens it.

Cost worth reviewing: the compiler could not tell a date from a timestamptz (both are time.Time in ColumnInfo.Type), so the logical type now rides the struct tag as type:date and lands in ColumnInfo.PGType — for every column. That regenerates models_gen.go across the repo and grows every tag. Describe.SQLType is the hand-written half.

One of the test updates was a real catch: TestNoOverridesChangesNothing asserted !contains(models, "uuid") to mean "no uuid import", and every uuid column now says uuid in its tag — it would have passed for the wrong reason forever. It looks for the import path now.

Not fixed: schema.TypeTime has the same defect on paper, but nothing round-trips a TIME column and pgx's mapping for it could not be verified here, so casting it would be a guess.

---

ad1e164 — ON CONFLICT DO UPDATE assigns an expression (#90)

OnConflictUpdate([]string{"key"}, "payload").
    OnConflictSet("updated_at", sqlb.Now()).
    OnConflictSet("hits", sqlb.Add(sqlb.Current("hits"), sqlb.Val(1)))

Both constraints the issue asked to settle in the same change:

• the qualifier is required. Both rows are in scope inside DO UPDATE, so count = count + 1 reads like an accumulation whichever side it resolves to. Excluded and Current name them, and a bare Field is refused — the expression is walked to find one, Raw exempt as always;
• names go through the model on both sides of the assignment, so a typo is an error from sqlb rather than a 42703 at request time.

Assignments share the statement's bind numbering, so a parameterised assignment is an ordinary $n.

Not in the issue and would have been a bug: DO NOTHING was chosen on len(doUpdate) == 0, so an upsert carrying only an assignment — the updated_at = now() case the issue opened with — would have compiled to a statement that writes nothing.

New vocabulary kept to what the three cases need: Excluded, Current, Now, Val, Add, Sub. COALESCE needed nothing — Selection.Expr() already made Coalesce usable here.

docs/release-1.0.md moves this from Before 1.0 to Done.

---

---

34184e1 — a computed column is opt-in (#92)

A computed column is declared on the model and wanted by one screen; everything reading the model paid for it. Three aggregates declared for a list attached a correlated subquery each to every read — including an existence check by id — and a column declaring Needs made those reads fail, asking a query that only wanted to know whether a row exists for a viewer bind it had no business supplying.

sqlb.Query[Project]().WithComputed("total_tasks", "is_starred")
rest.Options{Computed: []string{"total_tasks", "is_starred"}}

The issue proposed this at rest.Options. That alone would not have fixed it: the query that failed is hand-written and never goes through rest, so the default projection is where it moved.

For a resource it is a boundary rather than a projection setting — a column the resource does not select is not filterable, sortable or nameable in ?select there either. A filter on a correlated subquery costs what the projection would have.

Three consequences:

• the obligation moved with the selection. checkObligations read the model, so every mount of a model declaring a Needs column inherited the hook requirement. It now asks only of resources that render one;
• the response shape got honest. binding.selectable drives the JSON keys as well as the SELECT list, so an unselected computed column is absent from the body rather than present holding its zero value;
• generated resources are unchanged — codegen emits Computed listing the table's own computed columns. Worth reviewing as a deliberate deviation from "defaulting to none": none for a hand-written mount, everything-declared for a generated one.

---

e0bd206 — a text expression may be Searchable (#93)

?search fanned out over the resource's own columns only, so a chat named in the UI by its participants — a direct message has no name at all — found nothing for exactly the rows a search is for, and answered 200.

The refusal that closed the workaround gave this reason in both places it appeared: "?search fans out over text columns with ILIKE, and an expression has no reading there." That is a claim about type, and schema/registry.go:229 already makes it directly — Searchable requires a text column has always applied to computed columns too. So the blanket refusal added exactly one thing: the refusal of a computed column whose declared type is text, which is the only way to search across a relation. Removed; a Searchable bool expression is still refused by the general rule.

The cost half is answered by #92 landing first: the fan-out is gated on the same per-resource opt-in, so a mount that does not select the expression does not search it. That gate is load-bearing — without it the opt-in would govern the projection and leak on the path that runs the subquery most.

---

---

641ac0d — the Go client is its own package (#97)

A Go program that wanted the typed client had to import a package carrying cobra and a whole command tree. Two packages now:

cli/client/client_gen.go   Client, Request, Transport, Do, Run, Problem — stdlib only
cli/cli_gen.go             the cobra tree, importing the above

Three functions were the entire coupling: run, which took a *cobra.Command, and the two flag helpers. run became an exported Run(ctx, io.Writer, req, all), and the CLI keeps a four-line runRequest bridging cobra to it.

Two knobs, composing. ClientDir alone emits the client and no command tree; CLIDir emits both, defaulting the client to a client/ subdirectory so an existing consumer keeps working. ClientImportPath overrides the derived import path, which comes from the nearest go.mod plus Dir.

The old file's argument is answered, not dropped. It argued for one file on the grounds that a split import set would depend on which operations a schema exposes — and fail at the consumer's build, since gofmt parses an unused import happily. That is real, so the CLI's imports are now derived from the rendered body rather than written down, with a test that fails on any import the body never refers to.

Worth reviewing: run had to become runRequest, because example/tasks/cli/cli_test.go has a hand-written run and the first build after the split failed on the redeclaration. Any short generated identifier is a hazard in a package the consumer also writes in.

Docs: docs/cli/README.md is retitled Go client and CLI with a Just the client section, and README + docs/architecture.md name the client half — the issue's point that three external readers concluded sqlb emits no Go client because every mention described only a CLI.

---

---

96a43a5 — FromGo is cut (#17)

Docs only. ADR-0041 named FromGo the tier most likely to be cut and wrote the condition for cutting it — "if the first two applications express everything in SQL" — and both have: example/computed's three computed values are all FromSQL, and the multi-app adoption's five are tiers 1–3 (#92). codegen/schemasrc.go can only emit FromSQL, so the round trip could not have carried the tier anyway.

Two changes in this same PR narrowed the space it would have occupied: #93 made a text expression over a related table declarable, and #92 removed the cost argument for keeping derived work out of SQL.

The ADR gains a FromGo is cut section carrying the evidence, a struck-through trigger with the date it fired, and a note on what the cut does not claim — nobody tried it and found it wanting; nobody reached for it, which is weaker and is the evidence the trigger asked for. The taxonomy keeps four rows.

Verification across all six

go test ./..., go vet ./... and gofmt -l are clean. pgtest is a separate module: it vets clean but could not be run here (no Docker), so the six live-database tests added across these commits are unverified. They are the ones that actually prove #84 and #90 — worth a CI run before merging.