Code Generation Triggers

Two kinds of VALUES(…) derived tables built by Graphitron when batching:

@condition on lookup fields is allowed. The condition method, however, must preserve the N × M positional contract: each (source, target) pair produced by the derived-table cross join is either kept in full or dropped in full, and no additional rows may be introduced. In practice this means the condition should be a predicate over the pair of rows, not a filter that can change the per-parent result cardinality non-uniformly. Violating the contract desynchronises batch dispatch ; the client receives rows that cannot be reattached to their source. The contract is a developer responsibility, not a build-time check.

Two directives change the shape of the batch rather than what a coordinate classifies as.

@splitQuery on a field whose parent is bound to a table forces a new SQL statement, dispatched through a DataLoader keyed by the parent’s key columns. On a field whose parent is class-backed it is redundant, because the handoff into that parent already opened a new statement; that case is a build warning, not an error.

@lookupKey turns the field’s argument values into the derived target table above. It blocks pagination, which is what preserves the N × M result invariant, and it does not by itself open or close a statement. A field can carry both directives; the lookup rides along on whatever statement @splitQuery opened.

A type carrying @table(name:) classifies as TableType, the pivot for SQL generation, unless a nodehood or discrimination trigger takes precedence: @node, @discriminate, or implements Node over a table whose jOOQ class publishes NODE_TYPE_ID / NODE_KEY_COLUMNS. A root field returning a TableType enters a new query scope rooted in that table, and a scalar child whose name matches a column projects inline.

Film classifies as TableType (full SQL generation: queries, joins, projections); Query.film enters the scope; Film.title projects an inline column. The root type itself classifies as RootType, which is a fetchers class and nothing more: a root type binds no table, so it opens no query scope of its own and only wires the fields hanging off it. Asserted by the catalog corpus example via @classifiedType(as: TableType) on Film and @classifiedType(as: RootType) on Query. The field descriptions are written on the coordinates themselves, in the corpus document, so the sentence teaching a coordinate lives where the coordinate does.

A @table type that also carries nodehood classifies as NodeType rather than TableType: either @node(keyColumns:) written on it, or implements Node over a table whose jOOQ class publishes NODE_TYPE_ID and NODE_KEY_COLUMNS. Nodehood is a stronger claim than table-binding, so it takes precedence. The @nodeId field is where it shows: the coordinate carries an authored NODE_ID claim, and the emitted fetcher encodes the key columns into a Relay global id rather than projecting a column.

Note the tier: NODE_ID is authored, where Film.title in the first example was inferred. The directive is what makes the difference, and it is the anti-join in intent_resolved_field_claim that records it: an authored claim at a coordinate masks any structural reading there. Asserted by the node-type corpus example via @classifiedType(as: NodeType).

@nodeId encodes a type’s key columns into one opaque id. The key does not have to be a single column, and the id can be produced from a table other than the one that defines the type: written with typeName:, @nodeId names the type whose key shape to encode, and reads the columns for it from wherever the coordinate sits.

Both @nodeId coordinates claim NODE_ID and both emit, with or without typeName:. The difference is which key shape gets encoded, not which verdict is reached. Asserted by the composite-node-key corpus example.

An object type carrying no @table and reached from no producer is a grouping type: it has no table of its own, and its fields resolve against whatever scope its parent opened. It generates a fetchers class, because its fields still need wiring, but it opens no query.

FilmDetails.title and FilmDetails.description read columns of film, the table its parent bound, which is what "nested under the parent’s scope" means concretely. They fold into the parent’s SELECT and are projected inline, so the grouping object itself needs no query of its own: Film.details is wired as a passthrough that hands the parent’s source object straight down. The parameter lists in the block are the tell. A coordinate with a read to launch takes a DataFetchingEnvironment; one that is only a value read off the row already in hand takes an Object. Film.details returns an object and still takes an Object, which is what makes it a passthrough rather than a fetch. Asserted by the nesting corpus example via @classifiedType(as: NestingType).

A scalar declaration carrying @scalarType(scalar:) names a public static final GraphQLScalarType constant, and that constant is the whole binding:

Both scalars classify as ScalarType, and neither generates anything of its own. What the verdict buys is a registration and a Java type. The constant is registered on the synthesized schema through .additionalType(…​), and graphitron reflects on its Coercing<I, O> to recover the Java type the scalar stands for.

The two coordinates show why that recovered type matters, because they are the two places it is consumed. Payment.amount is an ordinary column read whose projection needs a Field<X>, and X is what the reflection resolved. Query.price takes the scalar as a @service parameter, and the same resolution is what lets the argument bind to the method’s parameter type. Nothing about either coordinate’s own verdict changes: amount is the same TABLE_COLUMN a String column would be, and price is the same SERVICE any other service root is.

The spec’s own built-ins (Int, Float, String, Boolean, ID) register the same way, but their Java types come from a closed table rather than from reflection, because the spec binds those names. Writing @scalarType on one of them is a hard validation error rather than an override. A non-spec scalar with no @scalarType is the other error: it classifies as UnclassifiedType and the build points at @scalarType(scalar:) as the single fix, never falling back to Object.

Asserted by the scalar-type corpus example via @classifiedType(as: ScalarType).

The types so far took their verdict from a directive the author wrote. A type that carries no binding directive can still get one from Java, by sitting at the boundary where a @service method hands a value out or takes one in. Nothing is declared; the verdict is read off the method’s signature by reflection, and which leaf it lands on is simply what kind of Java thing the reflected class is.

Three kinds, and the same three on both sides. Take the result side first: the type is what a producer returns.

The three result types land on PojoResultType.Backed, JavaRecordType, and JooqTableRecordType, and the fourth ResultType leaf, JooqRecordType, is what a table-less jOOQ Record reflects to. All four generate the same thing: a *Fetchers class and nothing else. A backed type owns no SQL scope, because graphitron did not build the value, it received it.

What the leaf does decide is how a field on such a type resolves. Every one of them classifies as a plain field read, which is why all three child rows above say "no claiming directive": no directive claims them, and the resolution is structural. But the structure differs by leaf. PojoBacked.id resolves against a readable accessor, JavaRecordBacked.name against a record component, and JooqTableRecordBacked.title against a column of the record’s own table. A field naming something the class does not expose is a build error at that coordinate, not a runtime null.

The input side is the mirror image: the type is what a consumer takes.

Only the three roots appear, because an input type has no fields to resolve; it has fields to populate. The input leaves mirror the result ones (PojoInputType, JavaRecordInputType, JooqRecordInputType, JooqTableRecordInputType), and again none of them generates a class. What each one generates is the population code inside the root’s own fetcher, so the service body receives its declared parameter type rather than a Map.

The direction of the obligation flips here, and that is the part worth reading twice. On the result side an SDL field must find something on the class; a class member the schema ignores is simply not exposed. On the input side a Java record inverts it: the canonical constructor needs every component, so the input type must declare a field for each one. That is why JavaRecordBackedInput carries both name and value while JavaRecordBacked carries only name. A plain class does not invert it, because JavaBean population fills what it is given and leaves the rest at its default.

PojoInputType carries a second population it does not share with the others: an input type that no @service parameter ever reflects still classifies as PojoInputType, unbound. That input has no backing class at all, and its fields resolve per usage against each consuming field’s table, so the same input reused on two different tables resolves differently at each one.

Asserted by the result-backing and input-backing corpus examples.

Every type so far takes its values from something the generator can go and read: a table, a service return, a component of a record. An @error type is the one that does not. Its values come from a Java exception thrown while some other field was being resolved, and handlers: is where the author says which exceptions those are.

It also does not reach the schema on its own. It arrives through an errors: slot on a @service payload, and that slot is what wires the try/catch: the carrier’s error channel records which @error types this call can produce, so the generated fetcher knows what to map a caught throwable into.

path and message are required on every @error type, and graphitron supplies both values itself. That is why each gets a generated method taking the DataFetchingEnvironment rather than a source object: path synthesises from the execution context’s path, the SDL position the error fired at (a validation-derived source routes through GraphQLError.getPath() instead, so the per-element paths survive), and message resolves at build time to the handler’s description: when the author wrote one and to the source’s getMessage() when they did not.

Any field beyond those two is the author’s. severity is one, and its row reads no method of its own because nothing needs generating for it: the schema’s registration wires a PropertyDataFetcher straight onto the accessor, reading getSeverity() off whatever was caught. The accessor name is the field’s own unless @field(name:) names a different one. Graphitron does check at classify time that every extra field has an accessor to read from on every class in the channel, but that check fires on the carrier and not on the @error type, so an extra field never moves the type’s verdict away from ErrorType.

The payload’s data field is a plain passthrough over the record the service returned, the reflection-derived backing of the previous section. errors is not. It is the error channel’s own coordinate, and the method in its row is where a caught throwable becomes a list the wire can carry.

What that method looks like depends on how the carrier ships the errors, which the classifier resolves once, with the parent’s channel in scope, and which has three answers. Here the errors ride an error-list arm of the value the producer returned, so the emitted method takes the source and unwraps that arm, resolving to null on the success arm to honour the field’s nullability; that is the (Object) signature in the block above. A carrier that ships them out of band instead, on the result’s local context, emits a method taking the DataFetchingEnvironment and reading them back from there. A plain class-backed parent whose errors-shaped field is a slot the developer populated emits no method at all: the registration wires a PropertyDataFetcher onto the property, the way severity is wired above. Only that third form is a passthrough, and a producer-bound payload like this one does not take it.

The rest of the handlers: option set (SQL-state and vendor-code matching, validation fan-out, matches: message filters) is in docs/manual/reference/directives/error.adoc; the classification verdict does not vary with any of it.

Asserted by the error-type corpus example.

What is left here is the surface a worked example cannot show. The corpus renders patterns that classify and generate, so a deprecation warning and two rejections have no example to be pulled into; they stay stated rather than demonstrated.

Intermediate sealed interfaces (not shown in the table ; grouping nodes in the hierarchy): - TableBackedType ; groups TableType, NodeType, TableInterfaceType. Builders switch on this to detect table-mapped types. - ResultType and InputType group the reflection-derived leaves, four each, worked through under A Java class on either side of the boundary.

Two fields can share an identical (source, operation, target) verdict yet emit different SQL, because the fetcher/loader mechanism is derived, not asserted. The cleanest illustration is the new-query derivation: a @table child reachable by a foreign key from a @table parent inlines as a correlated subquery folded into the parent’s SELECT, while adding @splitQuery opens a new keyed query dispatched through a DataLoader. Both classify identically (source = Child(Table), operation = Fetch, target = Single(Table)); only the derived new-query layer differs, forced by the @splitQuery slot.

City.country and City.countrySplit return the same Country over the same city → country foreign key and carry the same Child / Fetch / Table verdict; @splitQuery flips only the derived new-query layer, not an asserted axis. Asserted by the child-table corpus example.

The two mechanisms are worth naming, because every @table child on the page is one or the other. Inline means a DSL.multiset correlated subquery projected into the parent’s $project block, and at single cardinality that subquery adds a .limit(1) and a read-side unwrap lambda to turn the one-row list back into an object. Split means an async DataLoader fetcher plus a rows*() method that takes the parent keys as a batch.

The target shape records what domain object the value is, and with it whether graphitron builds the SQL (catalog: Table / Column) or consumes a value it did not build (domain: Record / Field). Two scalar flavors hinge on the parent’s table-ness: a scalar under a @table parent projects a Column (a real database column graphitron projects), while under a record-backed parent (a plain object with no @table, here produced as a service method’s return type) a scalar projects a Field (a POJO property read off a record graphitron only reflects). A nested non-table object under a record parent is the object flavor of the same Field shape. All three are Fetch; the parent’s table-ness moves the source shape (Table vs Record) and with it the target shape across the build-vs-consume line.

Film.title classifies with target shape Column (title is a column of the film table graphitron builds the projection for). FilmStats.count, a scalar under the record-backed FilmStats, classifies with target shape Field (a property graphitron reflects). FilmDetails.stats, a nested non-table object under the record-backed FilmDetails, also classifies with target shape Field (its object flavor). All hold operation = Fetch; the two record-backed cases also carry source = Child(Record). Neither record-backed case emits SQL of its own: both are wiring values, and what the generator has to decide for each is only where on the backing object the value is, carried as the leaf’s sealed ValueLocator arm (a typed column, a resolved accessor, a by-name read, or graphql-java’s default property read). Asserted by the mapping corpus example.

A field returning an interface, a union, or a Relay Node is catalog-bound over the participant types: classification resolves the polymorphic type to its participant @table rows and projects each branch from the catalog. The target shape is therefore Interface / Union (the projection lands on participant table rows), with the participant set carried as a derived slot rather than as a distinct shape value. The operation is Fetch for interface and union fields (root or child) and NodeResolve for the Relay node / nodes roots; the new keyed query a plain-interface or union field opens (InterfaceField / UnionField, and the polymorphic roots QueryInterfaceField / QueryUnionField / QueryNodeField / QueryNodesField) is a derived new-query, not an asserted axis. The one structural difference is a @table+@discriminate interface child (TableInterfaceField / BatchedTableInterfaceField): it is foreign-key-correlatable from the parent, but the discriminated re-projection is still its own statement rather than a fold into the parent’s SELECT, so what the cardinality decides is how many statements, not whether there is one. It follows the same rule as the multi-table pair above, with the participant conjunct holding structurally (the parse boundary rejects a non-table implementor of a discriminated interface): list cardinality batches through a DataLoader, single cardinality fetches per parent. Either way its asserted Child / Fetch / Table verdict is the same.

Customer.address returns the plain interface Named (implemented by the @table type Address), so it classifies with source = Child, operation = Fetch, target shape Interface (InterfaceField): a derived new keyed query projects the participant table, with Address recorded as the participant slot. Named itself classifies as InterfaceType, the verdict for an interface carrying no @table of its own, and generates a fetchers class. Asserted by the interface corpus example via @classifiedType(as: InterfaceType).

A union child follows the same dimensional rule. The selection descends into each participant through an inline fragment (…​ on Film, …​ on Actor), and classification resolves the union to its participant @table rows:

FilmActor.related returns the union FilmOrActor, so it classifies with source = Child, operation = Fetch, target shape Union (UnionField): a derived new keyed query projects whichever participant table a row resolves to, with Film and Actor recorded as the participant slots. FilmOrActor itself classifies as UnionType and generates a fetchers class, the same shape InterfaceType gets: a union binds no table, and its participants carry the catalog binding. Asserted by the union corpus example via @classifiedType(as: UnionType).

The @table+@discriminate interface child is a further leaf on this same polymorphic rule, and the one where cardinality forks the delivery; it gets its own worked example under One table, many participants below. The Relay Node root (QueryNodeField, operation = NodeResolve, target shape Interface) is another, worked through under Any root that returns Node.

A discriminated interface may also be a joined-table (class-table) inheritance: each concrete type declares its own detail @table distinct from the discriminated base, with its inherited (base-resident) fields carrying a @reference back to the base and its own columns living on the detail table. Such a participant classifies as a ParticipantRef.JoinedTableBound carrying the resolved child-to-parent hop (rather than a single-table TableBound); its inherited field is a ColumnBackedReferenceField resolved on the base and its own field a plain ColumnBackedField on the detail table. The interface fetcher selects from the base and emits a discriminator-gated LEFT JOIN to each participant’s detail table, projecting the shared fields off the base and each participant’s detail-exclusive columns off its detail alias; the same concrete type is independently queryable on its own, resolving its inherited fields through the parent reference. The child-to-parent join must be PK=FK (the detail table’s foreign-key columns to the base are its own primary key, single-column or composite), which keeps the base-to-detail join single-valued. Asserted by the joined-table-interface corpus example.

@asConnection on a discriminated interface root moves the coordinate along the operations and target axes exactly as it does on a plain table root: the member set gains Paginate, and the target becomes Single of shape Connection. Nothing about the source axis changes, so the launch stays the discriminated composition and the page is cut over it.

That composition may be paginated because every join it emits is proven single-valued: the base-to-detail join is the PK=FK edge above, and a participant scalar reached one @reference hop off the base is projected as a capped correlated subselect, not joined in. LIMIT slices rows, so the property that makes a page correct is that one row is one entity; both facts above are what establish it, and totalCount counts the base under the same predicate the page ran under.

Asserted by the paginated-joined-table-interface corpus example.

The "`*Fetchers` Generates" column in the tables below names which of four emission paths a variant drives. The four are an exhaustive, disjoint partition of every field leaf, enforced by GeneratorCoverageTest.everyGraphitronFieldLeafHasAKnownDispatchStatus, so a new leaf cannot be added without declaring its path:

@lookupKey marks an argument whose values are the keys to look up. It is the only claim on this page written on an argument rather than on the field, and the claim still lands on the field: the coordinate reads LOOKUP_KEY, authored.

The contract on the root is positional: one output element per key passed, with null at the position of a key that matched nothing. That is what forces the return type’s elements to be nullable, and a [Film!]! there is an author error whose message says so. Film.filmId inside the looked-up rows is an ordinary inferred column read, unaffected by how its rows were reached.

The root’s read is synchronous. There is no parent set to batch over, so Query.filmById is a thin fetcher over a lookupFilmById rows method that runs the statement and returns its rows directly. A rows method is not by itself a sign of batching; it is what makes the read callable from outside the fetcher, so entity resolution can reach the same statement.

FilmActor.actors carries the same directive one level down and reads no claiming directive. Position is what decides. On a root there is nothing but the argument to say where the rows come from, so @lookupKey claims the coordinate. On a child the return type has already said it, and the argument only keys the correlated subquery the child was going to be either way, so the child keeps whatever verdict its return type gives it. The axis that does move is the operation: the child is Child / Lookup / Table rather than Child / Fetch / Table, and what it emits is the ordinary inline shape, a DSL.multiset correlated subquery whose keyset arrives as a VALUES join over the argument’s values. Asserted by the lookup corpus example.

A root field’s position is an axis value, not a separate classification: source = Query is what makes it a root, and the return type decides the rest exactly as it does on a child. The default case is the plain @table return of the @table type example, which emits a full fetcher: the condition call, the orderBy build, and the inline DSL chain (dsl.select(Type.$project(…​)).from(table)…​) that opens the query scope. The polymorphic returns are the polymorphic section above, where a root and a child differ only in where they arrive: a multi-table interface or union root emits per- participant polymorphic projection through a derived new keyed query, and a @table+@discriminate interface root is the discriminated composition shown there under @asConnection.

What is left is the @service pair, the failure row, and the Relay node roots, which get a worked example of their own at the end of this section:

The federation _entities field is not modelled as a QueryField permit; it is resolved by federation-graphql-java-support directly and dispatched through the generated EntityFetcherDispatch runtime helper. The corresponding entity-resolution metadata is carried in GraphitronSchema.entitiesByType.

A mutation whose @mutation(typeName:) writes the catalog and returns a @table type classifies with source = Mutation, the write verb as its operation (Insert / Update / Delete), and target shape Table. The write produces the affected row, then a follow-up SELECT re-projects it through the catalog; that read-back is the derived re-fetch (a write producer yielding a Table shape), not a separate asserted axis. The mutation’s input object is part of the rendered closure, so the excerpt shows the plain input the write consumes; the @table return names the write target:

Mutation.createFilm inserts a film row from FilmInput and projects the inserted row as the @table type Film: source = Mutation, operation = Insert, target shape Table (MutationField.DmlTableField carrying an Insert write arm), the read-back being the derived re-fetch. Asserted by the dml corpus example.

The other two write verbs differ from INSERT in what they can hand back, and the pair below is that difference alone: same claim, same tier, one returning the written row and one returning an id.

UPDATE behaves like INSERT: it writes, then re-projects the affected row, so its target shape is Table and the return type names the write target. DELETE cannot do that, because after the write there is no row left to project; RETURNING carries the primary key and nothing else, so the return tops out at an encoded ID and the target shape is Column. That is also why deleteFilm has to say @mutation(table: "film"): an ID return names no type, so the write target has nowhere else to come from. Both coordinates carry the same MUTATION claim at the same tier, which is the point: the verb is a slot of the claim, not a claim of its own. Asserted by the mutation-roots corpus example, which also pins the multiRow broadcast form of DELETE.

Three directives take a coordinate away from the catalog and put a producer behind it. All three land as an AUTHORED claim, and the claim name is what the outcome block shows.

@service names a Java method. What the generator does with its return depends on whether that return is a table type or not, and the pair below isolates exactly that: same directive, same parent, one returning @table rows and one returning a scalar.

The service returns values, and Film is a table type, so the values have to become table rows again: the coordinate opens a new keyed query, batched through a DataLoader, and Film.title reads a column of film inside it. Asserted by the service-table-child corpus example.

Change the return to a scalar and the re-query disappears, because there is nothing to look up:

Same verdict, same tier, and a fetcher method that hands back what the service returned. Asserted by the service-scalar-child corpus example.

Neither of those two verdicts is a statement about the parent. Move the same pair onto a parent that is not a table at all, a plain object whose backing class the generator reflects off its own @service producer, and the verdicts do not move:

The parent here is class-backed: no @table, no @record, its backing class reflected off makeLanguageKeyed’s return type. Its two children carry the same `SERVICE claim and the same two verdicts the @table-parented pair above carries, and filmsViaService still batches its Film rows through a DataLoader, keying the batch on the record the parent hands down rather than on a parent table row. What the parent’s shape moves is the source axis, Child(Record) instead of Child(Table), and the key the batch is built from with it. It does not move the claim, the target, or which leaf the coordinate lands on: both service leaves are minted under either parent, so no leaf name answers what arrives at getSource(). Asserted by the service-child-class-backed-parent corpus example.

The last pair separates two things that both look like "this column is not where you would expect". @reference keeps the value in the catalog and changes which table it is read from, so the claim stays TABLE_COLUMN and stays inferred: the name still matched, just at the far end of a named foreign key. @externalField takes the value out of the catalog entirely and claims the coordinate.

This is the clearest reading of what the tier column means. @reference is written on languageName and the tier is still inferred, because @reference is not a claiming directive: it moves the site the name resolves against, and intent_column_match_claim then matches there. Only @externalField claims, so only computedRating reads authored. Asserted by the reference-and-computed corpus example.

@routine points a field at a table-valued function instead of a table. The return type still binds a @table, because the function’s result set has a shape, and its children still resolve as columns of it. argMapping: binds the field’s GraphQL arguments to the function’s parameters by name.

ROUTINE is one of the claims intent_authored_field_claim carries, so the routine coordinate is authored while its children stay inferred column matches: from the children’s point of view nothing is unusual, they are reading a relation that happens to be a function result. Asserted by the routine-table-valued-read corpus example.

@asConnection rewrites a list field into a Relay connection. The connection, edge and page-info types do not exist in the schema the author wrote; they are synthesised for the coordinate and named after it. @asFacet on an input field adds facet counts computed over the same filter.

The coordinates named QueryFilmsConnection and QueryFilmsEdge are the synthesised types, and they emit fetchers of their own: that is what makes them visible here at all, since nothing in the authored SDL mentions them. Neither carries a claim, because @asConnection shapes the read rather than claiming the coordinate. Asserted by the faceted-connection corpus example, whose @synthesises assertion pins the full mint set including the facets and page-info types this query does not select.

Page-info is the one wrapper in that mint set that is not per-coordinate. A schema has exactly one PageInfo, landing on PageInfoType, however many connections it carries: the classifier synthesises it once when some connection exists and the author did not declare it, and reuses the author’s own declaration when they did, which is what a hand-written or federated schema relies on. The reused half is asserted by the connection corpus example, whose SDL declares the whole Relay triad outright.

@pivot reads a table whose rows are the values you want as fields, and turns one row per key into one field per key. The vocabulary argument names the enum whose values map to the key column, so the target type’s fields and the pivot’s rows line up by name.

No coordinate here carries a claim: @pivot and @reference are both shaping directives rather than claiming ones, and TranslatedTexts is a grouping type whose fields are filled from the pivoted aggregate rather than matched against a column. The nn and nb fields get their key values from the Sprak enum’s own @field(name:) renames. Asserted by the pivot corpus example.

The parent here is a type whose backing class is reflection-derived from its producer (a @service return, or a parent-accessor chain), not declared via a directive.

A class-backed parent is not a separate classification either. It moves the source axis to Child(Record) and, with it, the key the child’s query is built from; it does not move the claim or the target. The worked examples above cover most of what that means: scalars and nested non-table objects under such a parent in the target shape example, an FK-reached @table child in the record-handoff example, and both @service forms in the class-backed service pair, and the errors: slot in the @error example. What is left is the two forms no example shows, one of which does not currently generate:

InputField is a separate top-level sub-hierarchy of GraphitronField, alongside RootField and ChildField. It classifies input-object fields against the consuming field’s resolved table: the return-type table on the filter and arg-level @lookupKey paths, the write-target table on the DML paths.

*\* UnclassifiedField is a direct permit of GraphitronField; it is not nested under QueryField, MutationField, or ChildField. It is listed in the tables above for completeness, but structurally it sits at the top level of the sealed hierarchy. TableTargetField is an intermediate sealed sub-interface of ChildField grouping all 5 SQL-generating child field variants (TableField, BatchedTableField, TableInterfaceField, BatchedTableInterfaceField, ServiceTableField). The batched leaf is source-gated, and a @lookupKey correspondence rides on its fetch sibling as the seal’s LookupResolution arm rather than as a leaf of its own.