@multitableReference was the legacy generator’s escape hatch for fields returning a multi-table interface or union, where a single FK path could not describe the join because each implementation lived in a different table. The schema author declared a separate @reference-shaped routes entry per implementation type. The rewrite no longer supports the directive: multi-table interface dispatch is generated from @discriminate / @discriminator (with @reference for the FK-driven join), without a separate per-route description.

The directive name is still parsed (so existing schemas don’t fail with "unknown directive @multitableReference`"), but every application is rejected at classify time with a clear message: `@multitableReference is no longer supported. Remove the directive; the rewrite generates multi-table interface dispatch from @discriminate / @discriminator without an explicit multitable-reference path. Remove every occurrence from your schema and model the dispatch through @discriminate / @discriminator.

SDL signature

directive @multitableReference(
    routes: [ReferencesForType!]
) on FIELD_DEFINITION

Migration

Drop the directive (and its ReferencesForType argument tree) and model the multi-table dispatch through @discriminate / @discriminator. How-to: Polymorphic types covers the supported shapes:

  • @discriminate on the interface or union picks the right implementation per row.

  • @discriminator on the implementation declares the row-level discriminator value.

  • @reference on the field describes the FK-driven join (single hop, or multiple hops when the path traverses join tables).

The rewrite resolves the per-implementation join paths automatically from @reference and the catalog’s FK metadata; the schema author does not enumerate them.

Diagnostic

Any application of @multitableReference produces a build-time rejection:

@multitableReference is no longer supported. Remove the directive; the rewrite generates multi-table interface dispatch from @discriminate / @discriminator without an explicit multitable-reference path.

The rejection fires before the rest of the field’s classification runs, so the message is the first thing the build emits for that field. Schemas that still carry @multitableReference annotations must remove every occurrence to compile under the rewrite.

Constraints

  • Every application is rejected at build time, regardless of position. There is no "warn-only" mode and no migration shim, the surface is hard-removed.

  • The directive is still parsed (the schema still validates against the SDL), so the migration is a one-step delete-and-rebuild, not a two-step "first remove, then add @multitableReference back later".

  • The directive is mentioned in the rewrite’s directives.graphqls SDL only because removing the declaration would cause "unknown directive" parse errors on legacy schemas. Once your schema is fully migrated, the declaration is purely cosmetic.

See also

← Reference index