fastify-auto-sqlapi 0.1.13 → 0.2.0

package/AGENTS_BACKEND.md

@@ -357,6 +357,8 @@ buildRelation(mainSchema, mainField, joinSchema, joinField, options?)
 //   unique?: boolean;         // default false.
 //                             //   false → 1:N (child→main). Allowed in joinMustExist/joinMultiple/joinGroup.
 //                             //   true  → N:1 (parent→main). Allowed in joinLeft only.
+//   fields?: string[];        // allowlist of the target's fields reachable through this relation.
+//                             // Read joins only. Must include joinField. Everything else is 400.
 // }
 ```
 
@@ -367,6 +369,27 @@ buildRelation(mainSchema, mainField, joinSchema, joinField, options?)
 
 **When to declare an explicit `alias`**: only when (a) you join the same table multiple times in the same `allowedReadJoins`/`allowedWriteJoins`, or (b) you want a friendlier name in the public API surface than the SQL table name (e.g. `'orders'` instead of `'customer_order'`). Otherwise omit it — the default is `joinSchema.tableName`.
 
+**⚠️ A relation in `allowedReadJoins` is a read grant on the target table.** The join runs inside the query of the *host* table's route, so the target's `onRequests` never fire and its `operations` whitelist does not apply — a table with `operations: []` is still fully readable through any relation pointing at it. What does cross a join: `readExclude`, `tenantScope`, and the schema the relation was declared with.
+
+To expose a table broadly but keep some of its columns narrow, give the relation a `fields` allowlist:
+
+```typescript
+allowedReadJoins: [
+  buildRelation(SchemaAgent, 'userId', SchemaUser, 'id', { unique: true, fields: ['id', 'name'] }),
+],
+```
+
+The relation is declared against a schema narrowed to that list, so every read surface validates against it — `selection`, `filters`, `conditions`, `orderBy`, aggregations, and the generated request/response schemas. A field outside the list is `400 Unknown field` everywhere, not just missing from the projection, and the default `'*'` selection is spelled out into the allowed columns rather than emitting a real `SELECT *`.
+
+Rules, all enforced at declaration time:
+
+- **Must include the join field** — it is what correlates the fetched rows with the main ones.
+- **Not allowed on `allowedWriteJoins`** — the allowlist restricts reading only; write paths resolve `upsertMap` by schema identity and must write every column the caller sent. Declare two relations if the same pair is joined for reading and for writing.
+- **Computed fields on the target resolve against the narrowed schema** — one that reads a field outside the list is a `400`, so a computed cannot be used to reach past the allowlist. One that stays inside keeps working.
+- **Fail-closed** — a column added to the target later is not reachable through the relation until it is added to `fields`.
+
+`fields` is not a replacement for `readExclude` (which hides a column from the owning table's own routes too). See [ADR 0010](./docs/adr/0010-joins-do-not-run-route-guards.md) and [ADR 0011](./docs/adr/0011-join-fields-allowlist.md).
+
 **Choosing `unique`**: if `joinField` is the PK (or part of the composite PK) of `joinSchema`, the relation is N:1 — you almost certainly want `unique: true` so the alias is usable in `joinLeft`.
 
 **Owned child tables (translations, `*_info` details): use a writeJoin, not a standalone table.** A table that only exists as a child of a parent — e.g. `product_info` with composite PK `(product_id, lang)` — should be an `allowedWriteJoins` on the parent, not its own `DbTables` entry. The engine auto-fills the FK (`product_id`); add it to `upsertMap` (conflict key = the composite PK) to upsert children passing only their own fields. Avoids redundant endpoints/validators.
@@ -431,11 +454,15 @@ export const TableCustomer = defineTable({
 
 `extraFilters` accepts either a `Type.Object({...})` or a plain `Record<string, TSchema>`. Extra filter fields appear in Swagger but are NOT auto-applied as `WHERE col = value` — they are handled exclusively by the `extendedCondition` callback. The `filters` parameter in the callback is fully typed with autocomplete for all schema fields + extra filter keys.
 
+**Not available on `joinLeft`.** `extendedCondition` writes its own column references, which cannot be qualified with the `LEFT JOIN` alias the parent gets there, so `buildLeftJoinClauses` handles schema and computed fields only. The generated body schema does not advertise the parent's `extraFilters` under `joinLeft.<alias>.filters`, and sending one is a `400` rather than a silent no-op. Use `joinMustExist` on the same relation when you need an extra filter on the parent.
+
+**Unknown filter keys are a `400`** (`Unknown filter field: <key>`), on the main table and on every join. A filter that does not match a schema field, an `extraFilters` key or a computed field is rejected instead of dropped: silently ignoring it would return *more* rows than the caller asked for. The check lives in the engine, so it applies to `sqlApi.search()` too, and it runs before any query — the outcome never depends on whether the main query matched rows.
+
 ---
 
 ## Computed Fields (extension system)
 
-`computedFields` lets you declare **virtual fields** as SQL expressions on a per-table basis. Each computed becomes usable like a regular schema field across the search API: `filters` (equality), `conditions` (operators), `orderBy` (1-parte), `computeMin/Max/Sum/Avg`, and (opt-in) in `selectComputed` for the main response. Same machinery serves JSON column extraction, derived strings, dialect-aware date/calendar bucketing — without growing the library case-by-case.
+`computedFields` lets you declare **virtual fields** as SQL expressions on a per-table basis. Each computed becomes usable like a regular schema field across the search API: `filters` (equality), `conditions` (operators), `orderBy` (1-part), `computeMin/Max/Sum/Avg`, and (opt-in) in `selectComputed` for the main response. Same machinery serves JSON column extraction, derived strings, dialect-aware date/calendar bucketing — without growing the library case-by-case.
 
 ```typescript
 import { defineTable, exportTableInfo, Type } from 'fastify-auto-sqlapi';
@@ -519,7 +546,7 @@ For `joinLeft` specifically, the computed expr is automatically alias-prefixed b
 
 - **Bound `values` in computed expressions** work anywhere the expression lands in the `WHERE` clause or in `ORDER BY`: `filters` and `conditions` (main, `joinMustExist`, `joinMultiple`, `joinGroup`, `joinLeft`) and `orderBy`. The ConditionBuilder assigns the placeholder positions there, so no coordination is needed from the caller.
 - They are still rejected with 400 on `selectComputed`, `computeMin/Max/Sum/Avg`, `joinGroup.aggregations.by` and `defaultOrder`. Those expressions are emitted in the `SELECT` / `GROUP BY` list, which precedes the `WHERE` values in the parameter order — there is no correct position for them there. Most use cases (JSON extraction, concat, dateTrunc, simple ops) need no bound values at all.
-- **Computed CAN be used in `joinGroup.aggregations.by`** (just pass the computed name as a string). Bound `values` are not supported in this position (rejected with 400 — it is emitted in the `SELECT`/`GROUP BY` list). The existing FK-correlation rule for `orderBy <alias>.<fn>.<field>` still applies: 3-parti aggregation orderBy on a `by` that isn't the correlation FK is rejected — by definition a computed-by produces multiple groups per main row, so this is never valid.
+- **Computed CAN be used in `joinGroup.aggregations.by`** (just pass the computed name as a string). Bound `values` are not supported in this position (rejected with 400 — it is emitted in the `SELECT`/`GROUP BY` list). The existing FK-correlation rule for `orderBy <alias>.<fn>.<field>` still applies: 3-part aggregation orderBy on a `by` that isn't the correlation FK is rejected — by definition a computed-by produces multiple groups per main row, so this is never valid.
 - **Computed cannot be used as aggregation function** (`sum`/`min`/`max`/...). The values inside `aggregations.sum: ['<name>']` must be schema field names. To aggregate on a derived expression, declare the derivation as a computed and pass the computed name as the field, BUT only via `computeMin/Max/Sum/Avg` (top-level main aggregates), not the joinGroup ones.
 - **No chained computed** (a computed referencing another computed). Flat-only.
 - **Read-only**. Computed fields are not usable in insert/update bodies — the consumer's `expr` is for SELECT/WHERE/ORDER BY, never for writes.
@@ -608,8 +635,8 @@ const sqlApi = createSqlApi(db, dbTables, { dialect: 'mysql' });
 ```typescript
 // Search — full filter, join, pagination, aggregation support
 // orderBy supports two dotted notations:
-//   - 3-parti `<alias>.<fn>.<field>` for joinGroup aggregations (must be declared in the request body)
-//   - 2-parti `<alias>.<field>` for joinLeft parent fields
+//   - 3-part `<alias>.<fn>.<field>` for joinGroup aggregations (must be declared in the request body)
+//   - 2-part `<alias>.<field>` for joinLeft parent fields
 // See AGENTS_FRONTEND.md and BREAKING_CHANGES.md for the full reference.
 sqlApi.search(tableName, {
   filters?, conditions?,
@@ -777,7 +804,7 @@ Tables without `tenantScope` are unaffected — no filtering regardless of `getT
 - **All fields Optional in response**: `RETURNING *` may return any subset. Response schemas use `Type.Partial`.
 - **Nullable columns use `Nullable(T)` (type-array form)**: the generator emits `Type.Optional(Nullable(T))` for nullable columns — `Nullable` (exported by the package) produces `{ type: ['integer', 'null'] }`. Do NOT replace it with `Type.Union([T, Type.Null()])`: under Fastify's default Ajv `coerceTypes` a union corrupts values through its branches (`null` → `0` with the Null branch last, `0`/`""` → `null` with it first), while the type array validates and serializes NULL correctly. A bare `Type.Optional(T)` is also wrong: NULL serializes as `0`/`""`. In `filters`, an explicit `null` on a schema field builds `WHERE col IS NULL`.
 - **`excludeFromCreation`**: **IMPORTANT** — auto-increment PKs (e.g. `id` serial/auto_increment) MUST be listed here, otherwise INSERT will try to send them and fail. The CLI auto-detects this and adds it by default. Also useful for `createdAt`/`updatedAt` columns managed by DB defaults or hooks. It strips **client-supplied** values only: the payload is sanitized before `beforeInsert` runs, so a value the hook assigns to an excluded field (e.g. a server-generated TEXT id) DOES reach the INSERT. Same for the engine's FK auto-fill on secondaries — an excluded FK column does not suppress it. It is an **ergonomics tool for creation, NOT a field-level security mechanism**: it does not apply to updates — every Schema field is updatable by default, by design. Field-level update rules (`isAdmin`, roles, owner/tenant columns, state fields) are product logic: enforce them in `beforeUpdate` (silent strip) or `validate` (loud 400), or move the privileged transition to a dedicated endpoint and keep it off the auto routes via `operations`.
-- **`readExclude`**: fields hidden from every read — not projected by search/get, omitted from read response schemas and from this table's default (`*`) join selection when it is a join target. Referencing one from `filters`, `conditions`, `orderBy`, `joinGroup` aggregations or an explicit join `selection` returns 400: hiding a field from output while allowing it to be filtered would leak its value by bisection. **Writes are unaffected** — insert/update/bulk still accept the field, so a column can be writable but never readable (password hash, access token). Primary keys cannot be excluded. Complementary to trimming the Schema, which removes the column from reads *and* writes.
+- **`readExclude`**: fields hidden from every read — not projected by search/get, omitted from read response schemas and from this table's default (`*`) join selection when it is a join target. Referencing one from `filters`, `conditions`, `orderBy`, `joinGroup` aggregations or an explicit join `selection` returns 400: hiding a field from output while allowing it to be filtered would leak its value by bisection. **Writes are unaffected** — insert/update/bulk still accept the field, so a column can be writable but never readable (password hash, access token). Primary keys cannot be excluded. Complementary to trimming the Schema, which removes the column from reads *and* writes. It is **per table and static**: a column hidden here is hidden from every caller, including admins. To keep a column readable on the table's own routes but not through a relation, trim the Schema the *relation* is declared with instead — see the read-grant warning under [buildRelation](#buildrelation-signature).
 - **`upsertMap`**: when present for a schema, INSERT becomes upsert. PostgreSQL: `ON CONFLICT (...) DO UPDATE`. MySQL/MariaDB: `ON DUPLICATE KEY UPDATE`. Applies to both main and secondary tables.
 - **`schemaOverrides`**: override auto-generated schema fields with stricter TypeBox types (e.g. `{ email: Type.String({ format: 'email' }) }`). Overrides are merged into the body schema for insert, update, and bulk-upsert. The original Schema file is never modified. In updates, overridden fields are still wrapped in Optional (validates only when present). Overrides appear in Swagger.
 - **Validation receives camelCase**: `validate` receives the original camelCase record (as sent by the client) and secondaries. Field names match the schema definition, with full TypeScript inference (`main.startDate`, not `main.start_date`). It returns `ValidationError[]` — tuples of `[field, code]` or `[field, code, message]`. If any errors are returned, the request is rejected with 400 before hooks or SQL execute.

package/BREAKING_CHANGES.md

@@ -144,7 +144,7 @@ Real `LEFT JOIN` for N:1 (parent) relationships. The parent rows are returned in
 
 The engine attaches a real `LEFT JOIN <parentTable> AS <alias>` to the main query **only when needed**:
 - when the request includes `filters` or `conditions` on the parent (effectively turns into INNER JOIN behavior on those aliases — main rows whose parent doesn't match are excluded);
-- when `orderBy` uses 2-parti dotted notation referring to a parent field (`alias.field`).
+- when `orderBy` uses 2-part dotted notation referring to a parent field (`alias.field`).
 
 Otherwise only a side query `WHERE pk IN (distinct fk values)` is issued — no LEFT JOIN, no row duplication. Either way, the response shape is the same.
 
@@ -158,7 +158,7 @@ Otherwise only a side query `WHERE pk IN (distinct fk values)` is issued — no
 | `<alias>.<field>` | `joinLeft` (`unique: true` aliases) | orders main query by a parent field via LEFT JOIN |
 | `<alias>.<fn>.<field>` | `joinGroup` (declared in the same body) | orders main query by an aggregation via correlated scalar subquery |
 
-Ambiguity: 2-parti and 3-parti are disambiguated by counting dots. The 2-parti is rejected unless the alias is in `joinLeft` allowlist; 3-parti is rejected unless the alias is in the request `joinGroup` declaration.
+Ambiguity: 2-part and 3-part are disambiguated by counting dots. The 2-part is rejected unless the alias is in `joinLeft` allowlist; 3-part is rejected unless the alias is in the request `joinGroup` declaration.
 
 ## Response shape
 
@@ -248,7 +248,7 @@ If you used the join table's name as the secondaries key, change it to the new a
 
 `<table>.<fn>.<field>` still works for joinGroup, but `<table>` must now be the alias declared in `buildRelation`. If the alias differs from the old `tableName`, update the string.
 
-If you need to order by a parent field, **add a `joinLeft`-eligible relation** (with `unique: true`) and use 2-parti notation `alias.field` (NEW capability — not available before).
+If you need to order by a parent field, **add a `joinLeft`-eligible relation** (with `unique: true`) and use 2-part notation `alias.field` (NEW capability — not available before).
 
 ## Validation summary (400 responses)
 
@@ -257,8 +257,8 @@ The engine rejects, with `statusCode: 400`, any of:
 - `joinLeft` referencing an alias declared with `unique: false`
 - `joinMultiple`/`joinMustExist`/`joinGroup` referencing an alias declared with `unique: true`
 - request keys referencing an alias not declared in `allowedReadJoins`
-- `orderBy` 2-parti `<alias>.<field>` whose alias is not in `joinLeft`-eligible (i.e. `unique:true`) declarations
-- `orderBy` 3-parti `<alias>.<fn>.<field>` whose alias or `(fn, field)` pair is not declared in `joinGroup` for the same request
+- `orderBy` 2-part `<alias>.<field>` whose alias is not in `joinLeft`-eligible (i.e. `unique:true`) declarations
+- `orderBy` 3-part `<alias>.<fn>.<field>` whose alias or `(fn, field)` pair is not declared in `joinGroup` for the same request
 - `defineTable` with two `allowedReadJoins`/`allowedWriteJoins` entries resolving to the same alias (thrown at startup, not at request time)
 
 ---
@@ -380,3 +380,78 @@ endpoints previously behaved correctly for you — they are now gone and you mus
 - **First PK column is truly unique on its own?** Then the composite declaration was
   redundant: declare `primary: 'id'` (single) and keep the second column as a plain field —
   every by-id operation comes back.
+
+---
+
+# Breaking Change — unknown filter keys are rejected
+
+`filters` keys that match nothing are now a `400`, on the main table and on every join family.
+Previously they were dropped without a word.
+
+## Why this changed
+
+The engine only ever visited filter keys matching a schema field, an `extraFilters` entry or a
+computed field. Anything else — a typo, a renamed column, a field that exists on the table but
+not on the trimmed Schema a relation was declared with — was never looked at, and the query ran
+as if the filter had not been sent.
+
+That fails in the dangerous direction. A rejected filter returns *more* rows than the caller
+asked for, and nothing in the response says so; in an application where filters are also how
+visibility is narrowed, a typo becomes a data exposure. It was also the odd one out: an unknown
+field in `selection`, `conditions`, `orderBy` or a `joinGroup` aggregation has always been a
+400.
+
+## What changed
+
+| Request | Before | After |
+|---|---|---|
+| `filters: { nosuchfield: 'x' }` | `200`, filter ignored | `400 Unknown filter field: nosuchfield` |
+| `joinMultiple.<alias>.filters: { nosuchfield: 1 }` | `200`, filter ignored | `400 Unknown filter field: nosuchfield` |
+| `joinLeft.<alias>.filters: { <extraFilter> }` | `200`, filter ignored | `400 Filter '<key>' is an extraFilter: …` |
+| `filters: { knownField: undefined }` | ignored | ignored (unchanged) |
+| `filters: { knownField: null }` | `IS NULL` | `IS NULL` (unchanged) |
+
+Two related fixes ship with it:
+
+- The check runs in the engine, not in the route schema, so `sqlApi.search()` behaves the same
+  as the HTTP routes. (A closed `additionalProperties: false` schema would not have worked:
+  Fastify runs Ajv with `removeAdditional: true`, so it would have *stripped* the key and
+  reproduced the same silent behaviour one layer up.)
+- Join filters are validated **before any query runs**. They used to be validated inside the
+  side query, which is skipped entirely when the main result set is empty — so the same request
+  answered 400 or 200 depending on the data it matched.
+
+## Who is affected
+
+Callers that send filter keys the target table does not declare. Over-sending is the common
+case: a frontend that spreads a whole form state into `filters`, or reuses one filter object
+across two tables.
+
+## Migration
+
+Send only keys the table declares. `GET /agent/manifest` and the Swagger body schema both list
+them per table (schema fields + `extraFilters` + computed fields).
+
+For a form-state object, filter it before sending rather than relying on the server to ignore
+the extras:
+
+```typescript
+const ALLOWED = ['name', 'status', 'createdFrom'] as const;
+const filters = Object.fromEntries(
+  Object.entries(formState).filter(([k, v]) => ALLOWED.includes(k) && v !== '')
+);
+```
+
+Passing `undefined` for an absent value is still safe and needs no filtering: only keys with a
+defined value are validated.
+
+## joinLeft and extraFilters
+
+`joinLeft.<alias>.filters` used to advertise the parent table's `extraFilters` in Swagger and
+accept them at runtime, applying nothing: `buildLeftJoinClauses` builds its condition inline and
+never runs the target's `extendedCondition`, whose column references cannot be qualified with
+the `LEFT JOIN` alias the parent gets there. They are no longer advertised, and sending one
+returns a `400` naming the reason.
+
+Use `joinMustExist` on the same relation when you need an extra filter on the parent — that path
+delegates to the target's own `filters()` and does run `extendedCondition`.

package/CHANGELOG.md

@@ -9,8 +9,53 @@ Migration instructions for breaking changes live in **[BREAKING_CHANGES.md](./BR
 
 ## [Unreleased]
 
+### Changed
+
+- **Unknown `filters` keys are now rejected with `400 Unknown filter field: <key>`** instead
+  of being dropped in silence — on the main table and on every join family. The engine only
+  ever visited keys matching a schema field, an `extraFilters` entry or a computed field, so a
+  mistyped filter name came back as an unfiltered (wider) result set with no error: the
+  dangerous direction to fail in, and inconsistent with `selection`, `conditions`, `orderBy`
+  and aggregations, which have always answered 400. The check lives in the engine, so it
+  covers `sqlApi.search()` as well as the HTTP routes. `undefined` values still mean "filter
+  not supplied" and are ignored; an explicit `null` still filters by `IS NULL`. See
+  [BREAKING_CHANGES.md](./BREAKING_CHANGES.md#breaking-change--unknown-filter-keys-are-rejected).
+- **`joinLeft.<alias>.filters` no longer advertises the parent's `extraFilters`.** They were
+  present in the generated body schema and in Swagger, but `buildLeftJoinClauses` never runs
+  the target's `extendedCondition` (its column references cannot be qualified with the
+  `LEFT JOIN` alias), so the filter applied nothing. They are now rejected with a `400` naming
+  the reason and pointing at `joinMustExist` on the same relation.
+
+### Fixed
+
+- **Join validation no longer depends on the main result set.** `joinMultiple` / `joinLeft` /
+  `joinGroup` skip their side query entirely when the main query matched no rows, so everything
+  validated inside it was skipped with it — the same request answered 400 or 200 depending on
+  the data. This covered filter keys and `readExclude` on join filters, an explicit `selection`
+  naming an unknown field, and `joinGroup` aggregation fields including `aggregations.by`. Join
+  filters are now validated up front, and the selection and aggregation lists are resolved
+  before the empty-result bail-out.
+
 ### Added
 
+- **`fields` allowlist on `buildRelation`** — restricts which of the target table's fields are
+  reachable through one relation, without hiding them from the table's own routes the way
+  `readExclude` would. The relation is declared against a schema narrowed to the list, so
+  `selection`, `filters`, `conditions`, `orderBy`, aggregations and the generated
+  request/response schemas all reject anything outside it with `400 Unknown field`; the default
+  `'*'` selection is spelled out into the allowed columns instead of emitting a real `SELECT *`;
+  and computed fields on the target resolve against the narrowed schema, so one reading an
+  excluded column is a 400 rather than a way around the list. Declaration-time checks: the list
+  must include the join field, and is rejected on `allowedWriteJoins` (write paths resolve
+  `upsertMap` by schema identity and must write every column the caller sent). Fail-closed by
+  design — see [ADR 0011](./docs/adr/0011-join-fields-allowlist.md) for allowlist vs blocklist.
+- **[ADR 0010](./docs/adr/0010-joins-do-not-run-route-guards.md)** — a declared join is a read
+  grant: `onRequests` and `operations` are route-level and do not follow a join, so
+  `allowedReadJoins` grants read access to the target table under the *host* table's
+  authorization. Documents what does cross a join (`readExclude`, `tenantScope`, the relation's
+  schema), the trimmed-schema + explicit-`selection` pattern for column-level narrowing, and
+  the rejected alternatives (`canBeJoined` hook, `selection` as a ceiling).
+
 - **`excludeTables` config option** — blacklist for `sqlapi-generate-schema`. Tables
   listed in `excludeTables` in `sqlapi.config.ts` (exact names or `*` globs, e.g.
   `knex_*`) are skipped during schema generation; their previously generated schema files

package/README.md

@@ -266,6 +266,8 @@ const TableCustomer = defineTable({
     buildRelation(SchemaCustomer, 'id', SchemaOrder, 'customerId'),                       // alias = 'order'
     buildRelation(SchemaSession, 'userId', SchemaUser, 'id', { unique: true }),           // alias = 'user', N:1
     buildRelation(SchemaSession, 'updatedBy', SchemaUser, 'id', { alias: 'updater', unique: true }),
+    // `fields` restricts what this relation exposes of the target — read joins only
+    buildRelation(SchemaAgent, 'userId', SchemaUser, 'id', { unique: true, fields: ['id', 'name'] }),
   ],
   allowedWriteJoins: [
     buildRelation(SchemaCustomer, 'id', SchemaOrder, 'customerId'),                       // alias = 'order'
@@ -423,6 +425,43 @@ are always available to your own code.
 **3. Multi-tenancy** — `getTenantId` + `tenantScope` filter every query by tenant (see
 [Multi-Tenant](#multi-tenant)).
 
+### A declared join is a read grant
+
+⚠️ **Neither of the first two layers follows a join.** `onRequests` and `operations` are
+properties of the routes generated *for* a table; a join is resolved inside the query of the
+**host** table's route, so the target's hooks never run and its `operations` whitelist does not
+apply. A table with `operations: []` — no HTTP routes at all — is still fully readable through
+any relation pointing at it.
+
+So `allowedReadJoins` is a security decision: declaring a relation grants read access to the
+target table under the **host** table's authorization.
+
+What does follow a join: `readExclude`, `tenantScope`, and the schema the relation was declared
+with. To expose a table broadly while keeping some columns narrow, give the relation a `fields`
+allowlist:
+
+```typescript
+allowedReadJoins: [
+  buildRelation(SchemaAgent, 'userId', SchemaUser, 'id', {
+    unique: true,
+    fields: ['id', 'name'],   // everything else on `user` is unreachable here
+  }),
+],
+```
+
+Every read surface validates against it — `selection`, `filters`, `conditions`, `orderBy`,
+aggregations, and the generated request/response schemas — so `email` is `400 Unknown field`
+everywhere, not just missing from the projection. It is fail-closed: a column added to `user`
+later is not reachable through this relation until it is added to the list.
+
+`fields` restricts **reading** only, and only through that relation. It is not a replacement for
+`readExclude` (which hides a column from the table's own routes too) or for `onRequests` (which
+decides who may call them).
+
+Full rationale and the rejected alternatives in
+[ADR 0010](./docs/adr/0010-joins-do-not-run-route-guards.md) and
+[ADR 0011](./docs/adr/0011-join-fields-allowlist.md).
+
 ### Request limits
 
 Two hard caps bound how much work a single request can trigger (defense against accidental or
@@ -439,11 +478,14 @@ capped — they run your own trusted code.
 
 ### Write whitelist
 
-Insert/update/bulk-upsert bodies reject **unknown properties** (`additionalProperties: false`):
-only columns present in the generated Schema (as narrowed by `schemaOverrides` /
-`excludeFromCreation`) can be written. An unexpected field is a `400`, never a silently-written
-column — the Schema is the write whitelist. Trim the generated Schema (or use `excludeFromCreation`)
-to keep sensitive columns out of it.
+Insert/update/bulk-upsert bodies are `additionalProperties: false`: only columns present in the
+generated Schema (as narrowed by `schemaOverrides` / `excludeFromCreation`) can be written. The
+Schema is the write whitelist. Trim the generated Schema (or use `excludeFromCreation`) to keep
+sensitive columns out of it.
+
+An unexpected field is **stripped, not rejected**: Fastify runs Ajv with `removeAdditional: true`,
+so the request succeeds and the column is simply never written. Mass assignment is prevented
+either way, but do not expect a `400` to tell a client its extra field was ignored.
 
 ### Field-level update rules are product logic — use the hooks
 
@@ -543,12 +585,12 @@ Search with filters, advanced conditions, pagination, ordering, joins, and aggre
 }
 ```
 
-- **`filters`** — equality-based, flat key/value. Supports schema fields + `extraFilters`.
+- **`filters`** — equality-based, flat key/value. Supports schema fields, `extraFilters` and computed fields. A key that is none of those is a `400 Unknown filter field: <key>` — a mistyped filter must never come back as a wider result set. An explicit `null` filters by `IS NULL`; `undefined` means "not supplied" and is ignored.
 - **`conditions`** — array of `{ field, method, params }`. Methods: `isEqual`, `isNotEqual`, `isGreater`, `isGreaterOrEqual`, `isLess`, `isLessOrEqual`, `isLike`, `isILike`, `isIn`, `isNotIn`, `isBetween`, `isNotBetween`, `isNull`, `isNotNull`.
 - **`joinMustExist`** — EXISTS-based filter: "main rows where at least one related row matches". Accepts `{ filters, conditions }` (both optional). Aliases must come from `allowedReadJoins` declarations with `unique: false`.
 - **`joinMultiple`** — fetches related child rows in a side query. Accepts `{ filters, conditions, selection }`. Same `unique: false` aliases.
 - **`joinGroup`** — aggregations on the related table. Supports `sum`, `min`, `max`, `avg`, `count`, `distinctCount`, and optional `by` for GROUP BY (a schema field name or a computed-field name declared on the join table — e.g. for date bucketing declare a computed using `db.dateTrunc('month', qiCol('orderDate'))`). Accepts `{ filters, conditions }`. Same `unique: false` aliases.
-- **`joinLeft`** — embeds an N:1 parent. Real `LEFT JOIN` is added on demand (only when the request has `filters`/`conditions` on the parent or uses 2-parti `orderBy` on this alias). Aliases must be declared with `unique: true`. Accepts `{ filters, conditions, selection }`.
+- **`joinLeft`** — embeds an N:1 parent. Real `LEFT JOIN` is added on demand (only when the request has `filters`/`conditions` on the parent or uses 2-part `orderBy` on this alias). Aliases must be declared with `unique: true`. Accepts `{ filters, conditions, selection }`. Its `filters` accept schema and computed fields only: the parent's `extraFilters` need an alias-aware `extendedCondition`, so they are rejected with a `400` here instead of being silently ignored — use `joinMustExist` on the same relation when you need one.
 
 **Dot-notation in `orderBy` and `conditions`**:
 

package/dist/bin/generate-schema.js

@@ -6,6 +6,83 @@ import { buildConnectionString, introspectTables } from '../lib/cli/pg-introspec
 import { buildMysqlConnectionConfig, introspectMysqlTables } from '../lib/cli/mysql-introspect.js';
 import { applyExcludeTables, buildTableMap, generateSchemaFile } from '../lib/cli/schema-codegen.js';
 import { loadEnvFile, CONSOLE_COLORS, display, displayAsTableRow, parseArgs, runCli } from './utils.js';
+const STATUS_COLOR = {
+    created: CONSOLE_COLORS.green,
+    updated: CONSOLE_COLORS.cyan,
+    untouched: CONSOLE_COLORS.gray,
+};
+function introspect(dialect, schema) {
+    if (dialect === 'mysql' || dialect === 'mariadb') {
+        const connConfig = buildMysqlConnectionConfig();
+        return introspectMysqlTables(connConfig, connConfig.database);
+    }
+    return introspectTables(buildConnectionString(), schema);
+}
+/** Narrow the map to the `--tables` selection. Returns false when nothing matched. */
+function keepOnlyRequestedTables(tableMap, tableNames) {
+    if (!tableNames.length)
+        return true;
+    for (const schemaName of Object.keys(tableMap)) {
+        if (!tableNames.includes(tableMap[schemaName].name)) {
+            delete tableMap[schemaName];
+        }
+    }
+    return Object.keys(tableMap).length > 0;
+}
+function fileStatus(filename, content) {
+    if (!fs.existsSync(filename))
+        return 'created';
+    return fs.readFileSync(filename, 'utf-8') === content ? 'untouched' : 'updated';
+}
+function writeSchemaFiles(tableMap, schemasDir) {
+    const report = { created: false, touched: false, untouched: 0, files: new Set() };
+    for (const schemaName of Object.keys(tableMap)) {
+        const { name: tableName, fields, colMap, primary } = tableMap[schemaName];
+        const filename = path.join(schemasDir, `${schemaName}.ts`);
+        report.files.add(`${schemaName}.ts`);
+        const content = generateSchemaFile(schemaName, tableName, fields, colMap, primary);
+        const status = fileStatus(filename, content);
+        if (status === 'created')
+            report.created = true;
+        if (status === 'untouched') {
+            report.untouched++;
+            continue;
+        }
+        fs.writeFileSync(filename, content);
+        displayAsTableRow(filename, status, 90, STATUS_COLOR[status]);
+        report.touched = true;
+    }
+    return report;
+}
+/**
+ * Delete `Schema*.ts` files no longer backed by a table — including the ones whose table
+ * was just excluded by config. Only safe when generating every table: with `--tables` the
+ * unlisted schemas are legitimately absent from `generated`.
+ */
+function removeOrphanSchemas(schemasDir, generated) {
+    let removed = false;
+    for (const file of fs.readdirSync(schemasDir)) {
+        if (file.startsWith('Schema') && file.endsWith('.ts') && !generated.has(file)) {
+            const filePath = path.join(schemasDir, file);
+            fs.unlinkSync(filePath);
+            displayAsTableRow(filePath, 'removed', 90, CONSOLE_COLORS.red);
+            removed = true;
+        }
+    }
+    return removed;
+}
+function reportOutcome(report) {
+    console.log('');
+    if (report.untouched > 0) {
+        display(`${report.untouched} schema(s) untouched`, CONSOLE_COLORS.gray);
+    }
+    if (report.created) {
+        display("Don't forget to git add your new Schema files.", CONSOLE_COLORS.magenta);
+    }
+    if (!report.touched) {
+        display('All schemas are already up to date.', CONSOLE_COLORS.magenta);
+    }
+}
 await runCli('fastify-auto-sqlapi: generating schemas', async () => {
     const cliArgs = parseArgs({
         output: { type: 'value' },
@@ -15,99 +92,34 @@ await runCli('fastify-auto-sqlapi: generating schemas', async () => {
     const config = await loadConfig();
     loadEnvFile(config.envFile);
     const dialect = (cliArgs.dialect || config.dialect || 'postgres');
-    const schema = config.schema || (dialect === 'postgres' ? 'public' : config.schema || 'public');
+    const schema = config.schema || 'public';
     const outputDir = path.resolve(process.cwd(), cliArgs.output || config.outputDir);
     const schemasDir = path.join(outputDir, 'schemas');
     if (!fs.existsSync(schemasDir)) {
         fs.mkdirSync(schemasDir, { recursive: true });
         display(`Created directory: ${schemasDir}`, CONSOLE_COLORS.green);
     }
-    let rows;
-    if (dialect === 'mysql' || dialect === 'mariadb') {
-        const connConfig = buildMysqlConnectionConfig();
-        rows = await introspectMysqlTables(connConfig, connConfig.database);
-    }
-    else {
-        const connectionString = buildConnectionString();
-        rows = await introspectTables(connectionString, schema);
-    }
+    const rows = await introspect(dialect, schema);
     if (rows.length === 0) {
         display(`No tables found in schema "${schema}".`, CONSOLE_COLORS.magenta);
         return;
     }
     const tableMap = buildTableMap(rows);
-    // Config blacklist: excluded tables are invisible to the generator, so their
-    // schema files (if any) fall through to the orphan cleanup below.
+    // Config blacklist: excluded tables are invisible to the generator, so their schema files
+    // (if any) fall through to the orphan cleanup below. Deliberately no early return when
+    // everything is excluded — that cleanup still has to run.
     const excluded = applyExcludeTables(tableMap, config.excludeTables);
     if (excluded.length) {
         display(`Excluded by config (excludeTables): ${excluded.join(', ')}`, CONSOLE_COLORS.gray);
     }
-    // Note: no early return when everything is excluded — the orphan cleanup below
-    // must still run to remove the schema files of freshly excluded tables.
-    // Filter tables if --tables flag is provided
     const tableNames = cliArgs.tables;
-    if (tableNames.length) {
-        for (const schemaName of Object.keys(tableMap)) {
-            if (!tableNames.includes(tableMap[schemaName].name)) {
-                delete tableMap[schemaName];
-            }
-        }
-        if (Object.keys(tableMap).length === 0) {
-            display(`No matching tables found for: ${tableNames.join(', ')}`, CONSOLE_COLORS.magenta);
-            return;
-        }
-    }
-    let somethingCreated = false;
-    let somethingTouched = false;
-    let untouched = 0;
-    const generatedFiles = new Set();
-    for (const schemaName of Object.keys(tableMap)) {
-        const { name: tableName, fields, colMap, primary } = tableMap[schemaName];
-        const filename = path.join(schemasDir, `${schemaName}.ts`);
-        generatedFiles.add(`${schemaName}.ts`);
-        const content = generateSchemaFile(schemaName, tableName, fields, colMap, primary);
-        let status = 'created';
-        let color = CONSOLE_COLORS.green;
-        if (fs.existsSync(filename)) {
-            status = 'untouched';
-            color = CONSOLE_COLORS.gray;
-            if (fs.readFileSync(filename, 'utf-8') !== content) {
-                status = 'updated';
-                color = CONSOLE_COLORS.cyan;
-            }
-        }
-        else {
-            somethingCreated = true;
-        }
-        if (status !== 'untouched') {
-            fs.writeFileSync(filename, content);
-            displayAsTableRow(filename, status, 90, color);
-            somethingTouched = true;
-        }
-        else {
-            untouched++;
-        }
-    }
-    // Remove orphan Schema*.ts files (only when generating all tables)
-    if (!tableNames.length) {
-        const existingFiles = fs.readdirSync(schemasDir);
-        for (const file of existingFiles) {
-            if (file.startsWith('Schema') && file.endsWith('.ts') && !generatedFiles.has(file)) {
-                const filePath = path.join(schemasDir, file);
-                fs.unlinkSync(filePath);
-                displayAsTableRow(filePath, 'removed', 90, CONSOLE_COLORS.red);
-                somethingTouched = true;
-            }
-        }
-    }
-    console.log('');
-    if (untouched > 0) {
-        display(`${untouched} schema(s) untouched`, CONSOLE_COLORS.gray);
-    }
-    if (somethingCreated) {
-        display("Don't forget to git add your new Schema files.", CONSOLE_COLORS.magenta);
+    if (!keepOnlyRequestedTables(tableMap, tableNames)) {
+        display(`No matching tables found for: ${tableNames.join(', ')}`, CONSOLE_COLORS.magenta);
+        return;
     }
-    if (!somethingTouched) {
-        display('All schemas are already up to date.', CONSOLE_COLORS.magenta);
+    const report = writeSchemaFiles(tableMap, schemasDir);
+    if (!tableNames.length && removeOrphanSchemas(schemasDir, report.files)) {
+        report.touched = true;
     }
+    reportOutcome(report);
 });