@metaobjectsdev/codegen-ts 0.24.4 → 0.25.0

package/src/templates/value-object-file.ts

@@ -23,6 +23,7 @@ import { renderEntityConstants } from "./entity-constants.js";
 import { renderFilterAllowlist, renderSortAllowlist } from "./filter-allowlist.js";
 import { renderFilterType } from "./filter-type.js";
 import { GENERATED_HEADER } from "../constants.js";
+import { namesRef, namesConstArg } from "../names.js";
 
 export function renderValueObjectFile(obj: MetaObject, apiPrefix = "", ctx?: RenderContext): string {
   const enumAliases = renderEnumTypeAliases(obj, ctx);
@@ -34,7 +35,20 @@ export function renderValueObjectFile(obj: MetaObject, apiPrefix = "", ctx?: Ren
   // FR-017 Tier 3: a TPH subtype also emits its field-metadata constants object
   // (the `<Sub>` const), so the React form generator can render per-field
   // labels / rules / inputs the same way it does for ordinary entities.
-  const tphConstants = tphSubtype ? renderEntityConstants(obj, apiPrefix) : null;
+  //
+  // §A6/§B2 — a TPH subtype declares no source.rdb of its own; it INHERITS the
+  // discriminator base's single shared table (`children()` is resolving — ADR-0039).
+  // `resolveObjectNames` therefore returns a DEFINED result for it (confirmed
+  // empirically: `name` is the BASE's physical table name, `fields` covers both the
+  // base's inherited columns and the subtype's own), and `namesFile()` really does emit
+  // a `<Sub>.names.ts` for it — this is not a case where the literal is correct and must
+  // stay. Same `namesRef` pair every other §A6 site builds; `ctx` is guaranteed present
+  // at every real call site (entity-file.ts and its reference/entity.ts mirror both
+  // always pass it) even though the parameter stays optional for a bare unit-test call.
+  const tphNames = tphSubtype && ctx !== undefined ? namesRef(obj, ctx) : undefined;
+  const tphConstants = tphSubtype
+    ? renderEntityConstants(obj, apiPrefix, namesConstArg(tphNames))
+    : null;
   // FR-017 Tier 3: per-subtype filter + sort allowlists, excluding the
   // discriminator (it's pinned by the per-subtype route path, so a client must
   // not filter on it). Included fields are the subtype's own + inherited base

package/src/templates/view-decl.ts

@@ -14,6 +14,7 @@ import {
 import type { ColumnNamingStrategy } from "../metaobjects-config.js";
 import { mapColumnType } from "../column-mapper.js";
 import { zodTypeFor } from "./field-meta.js";
+import { columnExpr, type ObjectNames } from "../names.js";
 
 export interface ViewDeclOpts {
   readonly dialect: "postgres" | "sqlite";
@@ -38,6 +39,31 @@ export interface ViewDeclOpts {
    * UpdateSchema, all of which already treat the PK as non-null.
    */
   readonly pkFieldNames: ReadonlySet<string>;
+  /**
+   * §A6 — the resolved names artifact supplying this declaration's COLUMN constants,
+   * plus the ts-poet symbol reference (`imp()`'d import of `<Object>Names`), when the
+   * names generator is in the run. Absent ⇒ every column stays a literal.
+   *
+   * Deliberately says nothing about the view's OWN physical name: the two answers come
+   * apart on a write-through entity, whose artifact holds the TABLE's name (its primary
+   * source) while this declaration binds the REPLICA view. Conflating them cost the
+   * write-through read model its column constants — it had to omit `names` entirely to
+   * stop the artifact's view name being emitted, and lost every
+   * `.fields.<f>.column` reference with it. The view's name is now the caller's to pass
+   * (see the `viewName` parameter), which is the only place that knows.
+   */
+  readonly names?: { readonly resolved: ObjectNames; readonly symbol: Code } | undefined;
+  /**
+   * The view's `@schema` — a bare name, or an EXPRESSION for it (a names constant).
+   *
+   * Passed in rather than derived from `names`, and for the same reason `viewName` is: a
+   * write-through entity's REPLICA view is a different source node from the one
+   * `<Entity>Names` resolves, so the artifact's `schema` there is the WRITE TABLE's and
+   * would be a confidently wrong answer. A caller whose artifact genuinely names this view
+   * passes the constant expression; the replica-view caller passes its own literal, which
+   * is consistent with that view's NAME already being a known literal for the same reason.
+   */
+  readonly schema?: string | Code | undefined;
 }
 
 /**
@@ -85,7 +111,10 @@ function viewColumnLine(f: MetaField, opts: ViewDeclOpts): Code {
       dollarType = code`.$type<Record<string, ${imp(`${vo.name}@${vo.module}`)}>>()`;
     }
   }
-  return code`  ${f.name}: ${colSym}(${JSON.stringify(spec.dbName)}${optsArg})${dollarType}${viewModifiers}`;
+  // A6 — reference the constant whenever the artifact is in the run AND carries this
+  // field. A lookup MISS is normal, not a divergence — see ViewDeclOpts.names.
+  const dbNameExpr = columnExpr(opts.names, f.name, spec.dbName);
+  return code`  ${f.name}: ${colSym}(${dbNameExpr}${optsArg})${dollarType}${viewModifiers}`;
 }
 
 /**
@@ -95,7 +124,13 @@ function viewColumnLine(f: MetaField, opts: ViewDeclOpts): Code {
  */
 export function renderExistingViewDecl(
   fields: readonly MetaField[],
-  viewName: string,
+  /**
+   * The view's own physical name: a plain string is emitted as a literal, a `Code` is
+   * emitted verbatim (a caller whose names artifact genuinely names THIS view passes
+   * `physicalNameExpr(names, viewName)`). See `ViewDeclOpts.names` for why this is not
+   * derived from that artifact here.
+   */
+  viewName: string | Code,
   viewVar: string,
   opts: ViewDeclOpts,
 ): Code {
@@ -103,11 +138,26 @@ export function renderExistingViewDecl(
   const viewModule = opts.dialect === "postgres" ? "drizzle-orm/pg-core" : "drizzle-orm/sqlite-core";
   const viewSym = imp(`${viewFn}@${viewModule}`);
   const viewColumnLines = fields.map((f) => viewColumnLine(f, opts));
+  const viewNameExpr = typeof viewName === "string" ? code`${JSON.stringify(viewName)}` : viewName;
+
+  // @schema — a view lands in a schema exactly as a table does, and migrate qualifies the
+  // `CREATE VIEW` it emits. Fixing the table binding and leaving this one would be the more
+  // dangerous half-job: the two would then disagree with each OTHER as well as with the
+  // database. Drizzle spells it with the same shape as the table case, `pgSchema(s).view(...)`
+  // — PgSchema carries `view` alongside `table`. sqlite is excluded for the same reason as
+  // there: no schema concept, and migrate refuses a non-default @schema on that dialect.
+  const viewSchemaExpr: Code | undefined =
+    opts.dialect !== "postgres" || opts.schema === undefined ? undefined
+    : typeof opts.schema === "string" ? code`${JSON.stringify(opts.schema)}`
+    : opts.schema;
+  const viewCall: Code = viewSchemaExpr === undefined
+    ? code`${viewSym}`
+    : code`${imp(`pgSchema@${viewModule}`)}(${viewSchemaExpr}).view`;
   return code`
 // View declaration — Drizzle uses this for typed SELECT queries.
 // The SQL view is created/managed by migrate-ts; .existing() tells Drizzle
 // not to attempt DDL for this declaration.
-export const ${viewVar} = ${viewSym}(${JSON.stringify(viewName)}, {
+export const ${viewVar} = ${viewCall}(${viewNameExpr}, {
 ${joinCode(viewColumnLines, { on: ",\n" })}
 }).existing();
 `;

package/src/templates/zod-validators.ts

@@ -51,19 +51,55 @@ import { isRequired } from "../column-mapper.js";
  * when the object is not a TPH subtype.
  */
 export function tphDiscriminatorPin(obj: MetaObject): { fieldName: string; value: string } | undefined {
-  // ADR-0039: own — super-resolution walk. A subtype declares its OWN
-  // @discriminatorValue (must not inherit one), and the base level is found by
-  // walking superResolved reading each level's OWN @discriminator.
+  // ADR-0039: own — a subtype declares its OWN @discriminatorValue (must not inherit
+  // one); the base level is found by the super-resolution walk in `tphDiscriminatorLevel`.
   const value = obj.ownAttr(OBJECT_ATTR_DISCRIMINATOR_VALUE);
   if (typeof value !== "string" || value === "") return undefined;
+  const level = tphDiscriminatorLevel(obj);
+  if (level === undefined) return undefined;
+  return { fieldName: level.fieldName, value };
+}
 
-  // Walk the extends chain to find the root carrying @discriminator.
+/**
+ * The discriminator BASE an object extends — the nearest ancestor declaring
+ * `@discriminator` — or undefined when there is none.
+ *
+ * The base is NOT the topmost ancestor: a multi-level hierarchy can extend further up
+ * past the level that owns the discriminator, and a route path composed against the
+ * wrong level names an endpoint nothing mounts. One walk, read by `tphDiscriminatorPin`
+ * and by `restPath` (api-surface.ts), so the pin and the address agree on which object
+ * is the base.
+ */
+export function tphDiscriminatorBase(obj: MetaObject): MetaObject | undefined {
+  return tphDiscriminatorLevel(obj)?.base;
+}
+
+/**
+ * True when this object itself DECLARES `@discriminator` — the level of a TPH hierarchy
+ * that owns the discriminator, whether or not any concrete subtype extends it yet.
+ *
+ * ADR-0039: own — `@discriminator` identifies a hierarchy LEVEL, so it is read own: a
+ * subtype inheriting the attr through `extends` must not be mistaken for a base. This is
+ * the one predicate the form generator's filter (`hasGeneratedForm`) and the `agent/ui.md`
+ * page both ask, so "is this a discriminator base?" has one spelling.
+ */
+export function declaresTphDiscriminator(obj: MetaObject): boolean {
+  return typeof obj.ownAttr(OBJECT_ATTR_DISCRIMINATOR) === "string";
+}
+
+/**
+ * The ONE super-resolution walk behind `tphDiscriminatorBase` and `tphDiscriminatorPin`:
+ * the nearest ancestor declaring a non-empty `@discriminator`, with the field name it
+ * declares. Returning both from one walk is what keeps the pin's field name and the
+ * base's identity from ever being read at two different levels.
+ */
+function tphDiscriminatorLevel(obj: MetaObject): { base: MetaObject; fieldName: string } | undefined {
   let cursor = obj.superResolved;
   while (cursor !== undefined) {
     // ADR-0039: own — super-resolution walk; read each level's OWN @discriminator.
     const fieldName = cursor.ownAttr(OBJECT_ATTR_DISCRIMINATOR);
     if (typeof fieldName === "string" && fieldName !== "") {
-      return { fieldName, value };
+      return { base: cursor as MetaObject, fieldName };
     }
     cursor = cursor.superResolved;
   }

package/src/view-context.ts

@@ -0,0 +1,88 @@
+// Selecting a field's view by the SURFACE that renders it (#356).
+//
+// A field may legally declare more than one `view.*` child and every one of them
+// survives the load, so an emitter reading `field.views()[0]` let DECLARATION
+// ORDER decide its output — and because several emitters read that same list,
+// one declaration drove three unrelated surfaces at once. Declaring a
+// `view.text` so a grid cell rendered as text silently degraded the generated
+// FORM to an `<input>`, and swapping two lines of JSON with no semantic change
+// flipped the form's `<select>` back. That is not a modelling mistake; it is the
+// only possible outcome when one declaration serves three readers.
+//
+// The selector is the view's `name` — a reserved structural key already legal on
+// every node — so this needs no new attribute, no provider and no
+// `metamodelVersion` move (ADR-0037 step 0: the vocabulary existed, only the
+// read was wrong). The same shape as #353's resolution.
+//
+// Two rules, and the second is the load-bearing one:
+//
+//   1. A field declaring ONE view keeps its exact current behaviour: that view
+//      applies to every surface, whatever it is named (or unnamed). Existing
+//      models are untouched by construction — a `name` is how a view is
+//      ADDRESSED by `extends` (ADR-0029 `Customer.priceCents.display`), and
+//      re-reading those names as surface names would break addressing.
+//
+//   2. A field declaring SEVERAL views must name one for the surface being
+//      rendered. No match is a hard error, not a fallback: falling back to
+//      `views()[0]` reinstates the positional read for exactly the multi-view
+//      case this exists to fix, and falling back to the inferred default turns a
+//      `name` typo ("forms") into a silently degraded control. A field cannot
+//      declare two views with the SAME name — the loader merges same-(type,
+//      name) siblings into one node — so a match is never ambiguous.
+
+import type { MetaField, MetaView } from "@metaobjectsdev/metadata";
+import { CodegenError } from "./errors.js";
+
+/**
+ * The surface a generated artifact renders, and therefore the `name` its
+ * emitter looks for among a field's views.
+ *
+ * These are the only two surfaces the packaged generators render. An owned
+ * generator (FR-040) targeting a third may pass its own name — `viewForContext`
+ * takes any string — but it then owns telling its authors what to name.
+ */
+export const VIEW_CONTEXT_FORM = "form";
+/** Both grid tiers (TanStack and Angular) render the same surface, so both ask for this. */
+export const VIEW_CONTEXT_GRID = "grid";
+
+/** Render `view.dropdown name="form"` / `view.text (no name)` for a diagnostic. */
+function describe(view: MetaView): string {
+  return view.name.length > 0
+    ? `view.${view.subType} name="${view.name}"`
+    : `view.${view.subType} (no name)`;
+}
+
+/** `Entity.field`, or just the field name when the field has no parent object. */
+function fieldPath(field: MetaField): string {
+  const owner = field.parent?.name;
+  return owner !== undefined && owner.length > 0 ? `${owner}.${field.name}` : field.name;
+}
+
+/**
+ * The view a field declares for `context`, or `undefined` when it declares none
+ * at all (the caller's existing "no view" path — an inferred default — applies).
+ *
+ * Uses the RESOLVING accessor (ADR-0039): a view inherited through `extends` is
+ * as much the field's view as one declared on it.
+ *
+ * @throws CodegenError when the field declares several views and none is named
+ *   for `context`. The remedy is in the message: name one of them.
+ */
+export function viewForContext(field: MetaField, context: string): MetaView | undefined {
+  const declared = field.views();
+  // One view (or none) is unambiguous: it applies to every surface, exactly as
+  // it did before this selector existed.
+  if (declared.length <= 1) return declared[0];
+
+  const match = declared.find((v) => v.name === context);
+  if (match !== undefined) return match;
+
+  throw new CodegenError(
+    `Field "${fieldPath(field)}" declares ${declared.length} views ` +
+      `(${declared.map(describe).join(", ")}) and none is named "${context}", so codegen ` +
+      `cannot tell which one renders the ${context}. Name one of them "${context}" — a ` +
+      `view's \`name\` selects the surface it renders ("${VIEW_CONTEXT_FORM}" or ` +
+      `"${VIEW_CONTEXT_GRID}"). A field declaring a SINGLE view needs no name: that view ` +
+      `applies to every surface.`,
+  );
+}