Prefix: walk_.
What the legacy classification walk concluded, kept while that walk is being retired. The rows exist so new derivations can be checked against the old code’s answers during the migration; when the walk is gone, the family goes with it.
Where to start
- walk_type_backing_class
-
What the legacy classification walk resolved a type’s backing class to: one row per registered type the walk bound to a Java class, and no row for a type it left unbacked.
How this family meets the others
store_-
1 foreign key from this family’s rows into that one.
Why the name is right
What the legacy classification walk registered and what it bound, transcribed in the walk’s own vocabulary: its registries' reach as membership rows, and its backing resolution as the differential a store-native derivation checks itself against. Naming the family for the retiring walk gives the name its own retirement clock: when the walk is gone, the family has no referent. Its relations retire on separate clocks under that one, each draining as its own consumer migrates.
walk_type_backing_class
What the legacy classification walk resolved a type’s backing class to: one row per registered type the walk bound to a Java class, and no row for a type it left unbacked. The differential intent_type_backing_class checks itself against while it is built; see the family header for the writer, the cadence, and why the relation stands alone. Three populations are deliberately absent, each because another relation already owns it. A @table-bound type is absent: the walk answers it with a table rather than a class, and that population is intent_bound_table’s, so a second transcription here would be a duplicate with worse provenance. A type two producers bound to different classes is absent: the walk resolves that disagreement by refusing to bind at all, which is the population the derivation surfaces as two rows plus a conflict view, so the shadow’s silence there is a recorded behaviour difference and not a defect on either side. And the kind of backing (record, plain class, jOOQ record) is absent as a column, because it is a property of the class the census already states, and re-transcribing it would carry the leaf taxonomy this relation exists to dissolve into the relation replacing it.
Primary key: (graph_name, type_name). Foreign key: (graph_name) references store_graph (graph_name).
graph_name(CHARACTER VARYING, not null)-
the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart
type_name(CHARACTER VARYING, not null)-
the SDL type the walk bound; always a type the walk registered, which no relation records any more, so the containment is asserted in Java where both populations are projected from one walked model. One row per type rather than per type and axis: an SDL name is an output type or an input type and never both, so the walk’s two-axis bookkeeping is internal to it and not a dimension of the answer
class_name(CHARACTER VARYING, not null)-
the binary name of the class the walk bound the type to, spelled as the jvm_ census spells a class name so the two join without normalising; a class the census never reached is still a row, since what the walk resolved is the fact here and whether the scan saw it is a separate question