Generic SDL transcription

A type name exists in this graph: the anchor every SDL fact, every directive decode and every type-keyed derivation hangs off.

What a field at a coordinate is: its type expression, its description, its default and the site that contributed it, hanging off graphql_field_element.

One directive an author applied, at the coordinate they applied it to: one row per application, however many sites the corpus writes them at.

A field’s own name meets the columns of the table its site navigates to, case-insensitively, with no directive involved.

45 foreign keys from this family’s rows into that one.

93 foreign keys from that family’s rows into this one.

3 foreign keys from that family’s rows into this one.

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

owning type of the field the argument sits on

the field name within the owning type

the argument name within the owning field

declaration order within the field

rendered type expression, as on graphql_field

the named type the expression bottoms out in; author-spelled, no FK

outermost non-null wrapper present

a list wrapper is present

item-level non-null when is_list; NULL otherwise

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Carried from the entry rather than left behind by the anchoring, because the four columns beside it describe a type expression exactly when this is 0 or 1 and a reader that must tell those from a deeper one has nothing else to ask. A reader without it parses type_sdl, which is what the macro expansion did to find the carriers it may expand

rendered default value, when declared

SDL description string, when the author wrote one

the SDL file the row was captured from

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the upper-cased form of the column beside it, for the case-insensitive match against sql_column’s column_name_upper and jooq_name_upper where @field(name:) was omitted and the argument name stands in as a column spelling. Generated, so nothing writes it and nothing can. The argument-site counterpart of graphql_field.field_name_upper, folded for the same one crossing and for no other: nothing compares one argument name to another case-insensitively

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

owning type of the field the argument sits on

the field the argument sits on, anchored by graphql_field_element

the argument name within the owning field

this row as graphql_element spells it, Type.field(argument:) in the specification’s grammar, the trailing colon included because the specification writes it; the join down from the supertype, on graphql_type_element.coordinate’s terms and written the same way

when the reading that derived this row ran, on graphql_element.touched_at’s terms. Swept per graph and after its children, a key-to-coordinate row being what a reader joins through and so outliving nothing that still points at it. NOT NULL on graphql_element’s reasoning: a sweep that skipped unstamped rows would not be a sweep

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside. No foreign key defends it: the parent is a row of whichever relation holds that kind, and picking the relation is a resolution

source column of the same. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the value exactly as written, in SDL. The decomposition of it is in graphql_ast_value_entry, one row per node of the expression, which is what a reader wanting the parts reads; this column is the whole literal in one string and is owed a removal once nothing reads it

the owning graph’s partition, carried from the entry this describes

the file the application was written in

line of the application, which is the entry’s own position

column of the same. Keyed by the position because a position is what an application has: a directive applied twice in one file is two rows here, and the name is what they share rather than what tells them apart

the directive name written here, without the at sign. The one column the five sites share, which is why this relation exists: a reader asking where a named directive was written joins this once instead of unioning five relations that differ only in what the application was written inside. What it was written inside is the parent hop graphql_ast_entry already carries, so the site is a join away and not a column here

when the reading that produced this row ran, carried from the entry this describes. The reading finishes by deleting its file’s rows carrying an older instant, and this relation is swept beside the arms that write it so a position the author removed leaves the hierarchy whole

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_directive_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the type expression exactly as written, wrappers and all, so nothing about what the author typed is lost to the four columns beside it

the type name at the bottom of the expression, the wrappers stripped. Unwrapped here because it is the graphql-java Type node read down its own spine, which is three lines in Java and a parser in SQL; nothing about the corpus is consulted, so this stays a transcription

whether the outermost wrapper is a non-null, which for a list is about the list and not its items

whether the expression is a list at its outermost non-null

whether the outermost list’s items are non-null, NULL when the expression is not a list at all. At list_depth 1 that is the named type’s own nullability; deeper, it is the nullability of the list one level in

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Here so the four columns beside it are complete rather than nearly: they describe a type expression exactly when this is 0 or 1, and a reader that needs to tell those cases from a deeper one asks this column instead of parsing type_sdl. Recording the depth rather than refusing the document, because a transcription records what the author wrote; that graphitron’s own wrapper algebra stops at one list is a fact about the generator and belongs in a detection over this column

the default value exactly as written, or NULL where none was

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

whether the definition carried the repeatable keyword

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_directive_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the location name written here, kept as written and not checked against the specification’s list, which is graphql-java’s to police and the schema problems' to report

the owning graph’s partition, carried from the element entry this is about

the file the element was declared in, the first of the three columns naming its position. The declaration is in the same file by construction, a node being written inside the file that holds it, so the position below names both

line of the element’s own position, the second

column of the same, the third; with the two columns above, a reference into graphql_ast_element_entry, and the whole grain. A position sits inside exactly one declaration, so this answers once per element and never twice

which of the three kinds of declaration was reached: a type declaration, the schema block, or a directive definition. Carried rather than left to be joined because the three are told apart in the entry supertype and a reader stopping here should not have to go back for it

line of the declaration reached, the first of the two columns naming it within the file above

column of the same. With the file name above, the key of graphql_type_declaration for a type, which is where the merge order that numbers a repeated directive application comes from. Stated here rather than at each consumer because the hop count differs by what the element is, nought for a declaration, one for a field or an enum value, two for a field’s argument, and a consumer that unioned an arm per depth would be re-deriving the parent chain the entries already hold

the graph_name of a row of this rule, which capture writes into graphql_ast_element_declaration.graph_name

the source_name of a row of this rule, which capture writes into graphql_ast_element_declaration.source_name

the source_line of a row of this rule, which capture writes into graphql_ast_element_declaration.source_line

the source_column of a row of this rule, which capture writes into graphql_ast_element_declaration.source_column

the declaration_kind of a row of this rule, which capture writes into graphql_ast_element_declaration.declaration_kind

the declaration_line of a row of this rule, which capture writes into graphql_ast_element_declaration.declaration_line

the declaration_column of a row of this rule, which capture writes into graphql_ast_element_declaration.declaration_column

the owning graph’s partition, carried from the entry this describes

the file the declaration was written in

line of the declaration, which is the entry’s own position

column of the same. Keyed by the position and not by the coordinate, two documents declaring one type being two rows here and one row in graphql_element, which is the whole difference between what a document wrote and what the corpus settled on

the coordinate this declaration names, in the specification’s grammar. A string the document’s own names compose and nothing else: no key into graphql_element, which does not exist when this is written and which is this relation’s composed counterpart rather than its parent. The subtypes each generate the same expression from their own columns, and this is where that spelling is stated once for a reader who wants the coordinate without knowing which kind declared it. The schema block’s $schema is the one spelling composed from no name at all, a schema block having none, and a dollar sign being illegal in a GraphQL name is what makes a constant safe here

when the reading that produced this row ran, carried from the entry this describes. The reading finishes by deleting its file’s rows carrying an older instant, and this relation is swept beside the arms that write it so a position the author removed leaves the hierarchy whole

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file the entry was written in; half of the position that is this relation’s whole key

line of the entry, 1-based per the graphql-java convention every entry relation follows

column of the entry, on the same convention. A position identifies a written thing, which is what lets one relation hold nineteen populations without a discriminator in its key, and what every subtype hangs its own foreign key on

which entry relation holds the rest of this row, named for the relation rather than for the grammar so a reader wanting more than the position and the tree joins the relation this names. Stored rather than derived from which subtype happens to hold a matching row, on graphql_element.element_kind’s reasoning: the writer knows it, and deciding it once at the write keeps every reader from asking

line of the entry this one was written inside, null at a root: a type declaration, a directive definition, the schema definition. This is where the entry stratum’s tree lives, and it lives here rather than on the subtypes because three of them have a parent whose relation is not fixed and could reference nothing at all

column of the same, null with its sibling exactly at a root

when the reading that wrote this row ran. Swept per file with the subtypes that key into it, a document’s reading being what claims its positions, and the subtypes swept first, a parent position outliving nothing that still points at it

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name of the declaration this node was written inside, held here as well as on that row so the coordinate beside it is a function of this row alone. Named for what it holds rather than for the hop, which is how the anchors spell it too. Not a second key: the key is the parent’s position, and one method writes both rows out of one parse of one file, which is what holds the two spellings equal. Not to be read as named_type beside it, which is the type this field returns where this is the type it belongs to

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_enum_value_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the directive name written here, without the at sign. Nothing says a directive of this name was defined anywhere: applying an undefined directive is a state this row holds and a schema problem reports

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_field_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name of the declaration the field was written inside, two hops up rather than one. Held here for the reason type_name is held one hop down on the relations that need only one: the coordinate names both ancestors, and a generated column reads no row but its own

the name of the field this argument was written inside, which is the parent this row’s position keys into. The pair with type_name is what the coordinate spells

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the type expression exactly as written, wrappers and all, so nothing about what the author typed is lost to the four columns beside it

the type name at the bottom of the expression, the wrappers stripped. Unwrapped here because it is the graphql-java Type node read down its own spine, which is three lines in Java and a parser in SQL; nothing about the corpus is consulted, so this stays a transcription

whether the outermost wrapper is a non-null, which for a list is about the list and not its items

whether the expression is a list at its outermost non-null

whether the outermost list’s items are non-null, NULL when the expression is not a list at all. At list_depth 1 that is the named type’s own nullability; deeper, it is the nullability of the list one level in

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Here so the four columns beside it are complete rather than nearly: they describe a type expression exactly when this is 0 or 1, and a reader that needs to tell those cases from a deeper one asks this column instead of parsing type_sdl. Recording the depth rather than refusing the document, because a transcription records what the author wrote; that graphitron’s own wrapper algebra stops at one list is a fact about the generator and belongs in a detection over this column

the default value exactly as written, or NULL where none was

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name of the declaration this node was written inside, held here as well as on that row so the coordinate beside it is a function of this row alone. Named for what it holds rather than for the hop, which is how the anchors spell it too. Not a second key: the key is the parent’s position, and one method writes both rows out of one parse of one file, which is what holds the two spellings equal. Not to be read as named_type beside it, which is the type this field returns where this is the type it belongs to

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the type expression exactly as written, wrappers and all, so nothing about what the author typed is lost to the four columns beside it

the type name at the bottom of the expression, the wrappers stripped. Unwrapped here because it is the graphql-java Type node read down its own spine, which is three lines in Java and a parser in SQL; nothing about the corpus is consulted, so this stays a transcription

whether the outermost wrapper is a non-null, which for a list is about the list and not its items

whether the expression is a list at its outermost non-null

whether the outermost list’s items are non-null, NULL when the expression is not a list at all. At list_depth 1 that is the named type’s own nullability; deeper, it is the nullability of the list one level in

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Here so the four columns beside it are complete rather than nearly: they describe a type expression exactly when this is 0 or 1, and a reader that needs to tell those cases from a deeper one asks this column instead of parsing type_sdl. Recording the depth rather than refusing the document, because a transcription records what the author wrote; that graphitron’s own wrapper algebra stops at one list is a fact about the generator and belongs in a detection over this column

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_field_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the directive name written here, without the at sign. Nothing says a directive of this name was defined anywhere: applying an undefined directive is a state this row holds and a schema problem reports

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name the declaration this node was written inside gives itself, held here as well as on that row so the anchor keyed by it needs no join to spell. Named for what it holds rather than for the hop, which is how the anchors spell it too. Not a second key: the key is the parent’s position, and one method writes both rows out of one parse of one file

the interface name written here. Nothing says a type of this name was declared anywhere: an implements clause naming an absent interface is exactly the state this row exists to hold

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name of the declaration this node was written inside, held here as well as on that row so the coordinate beside it is a function of this row alone. Named for what it holds rather than for the hop, which is how the anchors spell it too. Not a second key: the key is the parent’s position, and one method writes both rows out of one parse of one file, which is what holds the two spellings equal. Not to be read as named_type beside it, which is the type this field returns where this is the type it belongs to

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the type expression exactly as written, wrappers and all, so nothing about what the author typed is lost to the four columns beside it

the type name at the bottom of the expression, the wrappers stripped. Unwrapped here because it is the graphql-java Type node read down its own spine, which is three lines in Java and a parser in SQL; nothing about the corpus is consulted, so this stays a transcription

whether the outermost wrapper is a non-null, which for a list is about the list and not its items

whether the expression is a list at its outermost non-null

whether the outermost list’s items are non-null, NULL when the expression is not a list at all. At list_depth 1 that is the named type’s own nullability; deeper, it is the nullability of the list one level in

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Here so the four columns beside it are complete rather than nearly: they describe a type expression exactly when this is 0 or 1, and a reader that needs to tell those cases from a deeper one asks this column instead of parsing type_sdl. Recording the depth rather than refusing the document, because a transcription records what the author wrote; that graphitron’s own wrapper algebra stops at one list is a fact about the generator and belongs in a detection over this column

the default value exactly as written, or NULL where none was

the description written here, which is the node’s own, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside. No foreign key defends it: the parent is a row of whichever relation holds that kind, and picking the relation is a resolution

source column of the same. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the directive name written here, without the at sign. Nothing says a directive of this name was defined anywhere: applying an undefined directive is a state this row holds and a schema problem reports

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_schema_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the root operation named here, spelled as the author wrote it, which the grammar makes lower case. Not checked against the three the specification allows, on graphql_ast_directive_location_entry.location’s terms

the type name bound to that operation. Nothing says a type of this name was declared anywhere

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

whether this position extends the schema node rather than declaring it

the description written here, or NULL where none was

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_schema_definition_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the directive name written here, without the at sign. Nothing says a directive of this name was defined anywhere: applying an undefined directive is a state this row holds and a schema problem reports

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

which of the six declaration forms was written here, read off the node class the parser produced rather than off the text

whether this position extends a type rather than defining it. TRUE and FALSE are both ordinary states of a well-formed corpus, and a name carrying only extensions is an author error some detection reports, never a refusal here

the name written here, which is the node’s own getName(). Deliberately not unique: two positions naming one thing is the state this family exists to hold

the description written here, or NULL where none was. Always NULL on an extension, the grammar giving extensions nowhere to put one; stated in a comment rather than a CHECK, because a gatherer that refuses a row is a gatherer that stops gathering

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the directive name written here, without the at sign. Nothing says a directive of this name was defined anywhere: applying an undefined directive is a state this row holds and a schema problem reports

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node this one was written inside, and the first half of a key into graphql_ast_type_declaration_entry. Both are in this file and one reading writes both, so the reference is a constraint rather than a lookup a reader has to trust

source column of the same, and the second half of that key. No ordinal sits beside these two: within one parent the nodes of a kind are ordered by the position they were written at, which is the key

the name the declaration this node was written inside gives itself, held here as well as on that row so the anchor keyed by it needs no join to spell. Named for what it holds rather than for the hop, which is how the anchors spell it too. Not a second key: the key is the parent’s position, and one method writes both rows out of one parse of one file

the member type name written here. Nothing says a type of this name was declared anywhere, on graphql_ast_implements_entry.interface_name’s terms

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the file this node was written in. No foreign key here, deliberately: source_ref beside it carries the reference. A node is in the file it was written in by definition, so the attribution holds whether or not the registry still vouches for the reading

source line of the node, 1-based per the graphql-java convention

source column of the node, 1-based per the graphql-java convention. In the key because a line does not identify a node: minified SDL puts many on one line

a second copy of source_name, nullable, carrying the registry reference the key column cannot: one column cannot both refuse a delete and survive one. Deleting a registry row nulls this and deletes nothing, so a file that went away leaves this graph’s reading of it standing and flagged, and the owning graph reaps its own on its next refresh

when the reading that produced this row ran. The reading finishes by deleting its file’s rows carrying an older instant, which are the nodes the author removed and which an upsert alone cannot find. Not a modification time for the node, which is store_source.mtime’s

source line of the node the whole written expression belongs to: an applied argument, or an argument, input field or directive definition argument carrying a default. Repeated on every node of the tree rather than held only at its root, so one predicate fetches a whole expression and no reader walks upward to find out which slot it was written at. No foreign key defends it: the holder is a row of whichever of the four relations holds that kind, and picking the relation is a resolution

source column of the same

source line of the value this one was written inside, null at the root of an expression. Unlike holder_line this is a key back into this relation, because the enclosing node is a value and there is one relation for those

source column of the same

where inside the enclosing value this one was written: the index in a list, or the ordinal among an object’s fields. Null exactly at a root, which sits inside no value. Ordered by the author and not by anything read here, so a reader reproducing the expression sorts on it

the object field this value was written at, null when the enclosing value is a list and at a root. The field node itself gets no row of its own: a field is a name and a value, and the name is this column

which of the nine forms the parser read here. An attribute of the value and not a different fact, which is why one relation holds all nine: every row says the same thing, that this slot was written with this literal

the leaf’s text as the author wrote it, with a string’s quotes removed and nothing else interpreted: an int stays the digits, an enum stays the name, a boolean stays true or false. Null exactly for a list, an object and the null literal, which carry no text of their own. Not coerced to a type, because what a number means is a question for whoever anchors it against the argument’s declared type

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the applied or defined directive name, without the leading @

whether the definition says 'repeatable'; governs the ordinal on applications

SDL description string, when the author wrote one

the SDL file the row was captured from

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph through the element below; the leading key dimension that keeps one workspace’s graphs apart

the schema coordinate the application was written on, in the specification’s grammar: a type is its own name, a field or an enum value or an input field is the parent’s name and a dot, an argument goes one deeper, and the schema block is $schema. A reference into graphql_element, which is a table and not a union so this foreign key can name it, and the whole reason five relations are one: the coordinate is what every site has and the decomposed key is what none of them shares

the applied directive name, without the leading @

the repeat, numbered from zero within one coordinate and one directive name, in the order the declarations carrying them merge. A directive is not repeatable unless its definition says so, so on almost every application this is zero and the column exists for the ones that are

the file the application was written in, the first of the three columns naming its position. Nullable because a synthesised application has no position to name, an injector building a directive with no source location being a writer this relation admits rather than refuses

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total. The sweep is what collects an application an author deleted from a coordinate that still stands; a coordinate the author deleted takes its applications with it through the cascade above

the owning graph’s partition, carried from the application above; the leading key dimension that keeps one workspace’s graphs apart

the coordinate the owning application was written on, the second of the four columns naming it

the owning application’s directive name, the third

the owning application’s ordinal, the fourth; with the three columns above, a reference into graphql_directive_application

the definition’s formal argument this value binds, and the rest of the grain. An argument is named once inside one application, so nothing is ranked here; a document naming one twice is a schema problem and the upsert keeps the later of the two rather than refusing the row

the value as written, rendered from the AST. The literal rather than a parse of it, so an application is legible without knowing what the directive means, and so a consumer that does know reads the same string the author typed

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the applied or defined directive name, without the leading @

the argument name within the owning field

declaration order in the definition

rendered argument type, e.g. '[ReferenceElement!]!'

the named type the expression bottoms out in; author-spelled, no FK

outermost non-null wrapper present

a list wrapper is present

item-level non-null when is_list; NULL otherwise

rendered default; the value an application inherits when it omits the argument

SDL description string, when the author wrote one

position of the formal argument in the definition

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the directive the argument is declared on, keyed into graphql_directive_element, which is what makes an argument row unable to outlive the directive it belongs to

the argument’s own name, the second half of the key a reader holding a directive argument arrives with

the coordinate the specification spells for this argument, which is the directive’s coordinate with the argument name and a colon in parentheses. Unique on its own, the two keys being two spellings of one thing, which is what lets a reader holding the coordinate join back to the parts instead of taking the string apart by hand

when the reading that produced this row ran, swept on the same terms as the directive above it

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the directive’s name without the at sign, which is the key a reader holding a directive arrives with. graphql_directive carries what the definition says about itself; this carries only the coordinate, for the reason graphql_type_element is separate from graphql_type

the coordinate the specification spells for this directive, which is the at sign and the name. One row of graphql_element, and the foreign key says so: a directive is an element of the corpus in the same sense a type is, and this is the relation that decomposes its coordinate into the part a reader joins by

when the reading that produced this row ran. The reading finishes by deleting this graph’s rows carrying an older instant, which are the directives the corpus stopped declaring

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the applied or defined directive name, without the leading @

introspection location name, e.g. FIELD_DEFINITION, INPUT_FIELD_DEFINITION

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the coordinate itself, in the specification’s own grammar: Type for a named type, Type.field for a field of one, for an input field of one and for an enum value of one, and Type.field(argument:) for an argument of a field. Total by construction, which is what lets one column stand for a coordinate of any kind where the decomposed keys beside it cannot, the parts being different parts at each of the four. A relation naming a coordinate carries this column and a foreign key, and joins the subtype relation for the kind it cares about when it wants the parts. One coordinate here is ours rather than the specification’s: the schema block is $schema, which the grammar has no spelling for and which a relation keyed at a coordinate needs if the schema block is not to be the one site it cannot reach. A dollar sign is illegal in a GraphQL name, so it can never collide with a type an author declares

which kind of schema element this row is, in the specification’s own vocabulary, and so which relation beside this one a reader joins to get the parts, FIELD and INPUT_FIELD sharing one. All seven of the specification’s kinds appear here, and SCHEMA beside them for the block the specification gives no coordinate: the two directive forms joined the other five when a relation needed to name a deprecated directive and found the coordinate unanchored, and the schema block joined them when directive applications collapsed onto the coordinate and it was the only site left out. Stored rather than read off the spelling because Type.field spells a field, an input field and an enum value alike, the three being told apart by the parent type’s kind and not by the text; deciding it at the write, where the walk already knows which it is, is what keeps every reader from asking that question again

when the reading that derived this row ran. The derivation finishes by deleting this graph’s rows carrying a different instant, which are the coordinates the corpus stopped declaring. Swept per graph rather than per file because a coordinate is declared by the corpus and no one file’s reading can say it went away. NOT NULL, which is what makes the sweep total: a row with no instant would be a row no reading claims and no sweep reaches, so the column that decides what survives cannot be the one column a writer may forget

the owning graph’s partition, carried from whichever arm supplied the row

the coordinate as the specification spells it, unique within the graph and therefore the whole of what a reader joins on; carried from the arm’s own column, which is the same spelling graphql_element anchors

the type declaring the field the coordinate sits on

the field itself, within that type

the argument on an argument coordinate, NULL on a field coordinate. The discriminator between the two arms, and total against each of them rather than optional within either

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the owning ENUM type

the enum value name within the owning enum type

order in the effective enum: base declaration, then extensions

the contributing site, as on graphql_field

column of the contributing declaration site, the site key’s fourth part

SDL description string, when the author wrote one

NOT NULL for the same reason as on graphql_field: half of the site FK

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the owning ENUM type, anchored by graphql_type_element

the enum value name within the owning enum type

this row as graphql_element spells it, Type.value, which is the spelling a field of the same name would take; the parent type’s kind is what tells the two apart, and graphql_element.element_kind carries that decision so no reader repeats it. The join down from the supertype, on graphql_type_element.coordinate’s terms and written the same way

when the reading that derived this row ran, on graphql_element.touched_at’s terms. Swept per graph and after its children, a key-to-coordinate row being what a reader joins through and so outliving nothing that still points at it. NOT NULL on graphql_element’s reasoning: a sweep that skipped unstamped rows would not be a sweep

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

owning type

the field name within the owning type

order in the effective type: base declaration, then extensions in document order (capture merges them from the registry)

the contributing declaration site, keyed with this row’s own source_name (an authored row sits lexically inside its site; a synthesized row shares its synthesized site’s inherited position)

the site key’s fourth part, as on graphql_type_declaration

the rendered type expression, e.g. '[Film!]!'; authoritative for wrapping fidelity

the named type the expression bottoms out in; author-spelled, no FK, integrity is a detection

outermost non-null wrapper present

a list wrapper is present

item-level non-null when is_list; NULL otherwise

how many list wrappers the expression has: 0 for a named type, 1 for a list of one, 2 for a list of lists. Carried from the entry rather than left behind by the anchoring, because the four columns beside it describe a type expression exactly when this is 0 or 1 and a reader that must tell those from a deeper one has nothing else to ask. A reader without it parses type_sdl, which is what the macro expansion did to find the carriers it may expand

rendered default value; input-object fields only

SDL description string, when the author wrote one

every field row comes from an SDL site (built-in scalars declare none), and a NULL here would silently disable the site FK under MATCH SIMPLE

source line, 1-based per the graphql-java convention

source column, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the upper-cased form of the column beside it, for the case-insensitive match against sql_column’s column_name_upper and jooq_name_upper where @field(name:) was omitted and the field name stands in as a column spelling. Generated, so nothing writes it and nothing can. A GraphQL field name is folded here for that crossing alone; nothing compares one to another case-insensitively

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the owning type, anchored by graphql_type_element

the field name within the owning type

this row as graphql_element spells it, Type.field in the specification’s grammar; the join down from the supertype, on graphql_type_element.coordinate’s terms and written the same way

when the reading that derived this row ran, on graphql_element.touched_at’s terms. Swept per graph and after its children, a key-to-coordinate row being what a reader joins through and so outliving nothing that still points at it. NOT NULL on graphql_element’s reasoning: a sweep that skipped unstamped rows would not be a sweep

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the implementing type, which is the declaration this row hangs off

the interface named in the implements clause, author-spelled and unanchored

source order of this implementor among the interface’s implementors, numbered from one, which is what the merged relation counted and what a reader ordering them still expects. Not the interface’s position within this type’s implements clause: the split moved the key and left the numbering alone, renumbering being visible to a mapping-constant fingerprint. See graphql_union_member.position for why the two bases differ.

line of the declaration site that contributed this membership, as on graphql_field

column of the same, the site key’s fourth part

the file the member or interface token itself was written in; NOT NULL as on graphql_field

source line of that token, 1-based per the graphql-java convention

source column of that token, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

which arm this row came from, UNION or INTERFACE, which is also which base relation holds it; a literal in each arm of the union rather than a stored column

the union or the interface holding the member, whichever arm this row is

the member type on the union arm, the implementing type on the interface arm

source order within the container, as the arm that holds it recorded it

the type that declared this membership: the container on a UNION row, the member on an INTERFACE row. The anchored end, and what the two arms disagree about, which is why they are two relations

line of the declaration site that contributed this membership, as on graphql_field

column of the same, the site key’s fourth part

the file the member or interface token itself was written in; NOT NULL as on graphql_field

source line of that token, 1-based per the graphql-java convention

source column of that token, 1-based per the graphql-java convention

when the reading that derived the underlying row ran, carried through from the arm that holds it

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

which root slot

the object type serving it

position of the binding inside the schema { } block; all three NULL exactly when the binding is the name-convention default no SDL line spells

line of the binding; NULL with the siblings when the binding is the name-convention default

column of the binding; NULL with the siblings when the binding is the name-convention default

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

this problem’s place in the order its stage raised them, numbered from zero there rather than across the four. Part of the key because a problem need not carry a position, so there is nothing else that tells two of them apart; numbered per stage so the stage that raised them is the only thing that has to have held them

when the reading that produced this row ran; the reading finishes by deleting this graph’s rows that still carry an older instant, which are the problems the corpus no longer has

which reading refused: PARSE judged one file alone, REGISTRY combined the files, REWRITE composed them with the loading rewrites the generator runs (the federation @link’s imports, the configured tags and notes), ASSEMBLY made a schema of the result. Rows are numbered within the stage and written in the order the stages ran. A column rather than four relations, all four being what happened when we tried to make a schema out of these documents

the stage’s own name for the kind of problem, so a reader can group without parsing the sentence: graphql-java’s error class’s simple name at PARSE, REGISTRY and ASSEMBLY, and the refusal variant’s name at REWRITE (DeclarationCollision, MultipleFederationLinks and the like). Both are bare names, and the stage says which namespace a row is in

the refusing stage’s own sentence, kept verbatim: graphql-java’s at PARSE, REGISTRY and ASSEMBLY, graphitron’s fix-it prose at REWRITE, which is the sentence the build fails with. Rewording either here would make the store the second author of an error the build reports

the file the problem is about, where the stage knows one: always at PARSE, and at the other three whatever site the stage pointed at. No reference to store_source, deliberately: a row here is a transcription, and declining to record one because its file is not in the registry would lose the verdict this relation exists to keep

line of the site the problem points at, 1-based, or null where the stage reported none

column of that site, null exactly when the line is; graphql-java locates at the enclosing declaration rather than the offending element, so this is where to start reading and not where the fault is

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the type these attributes describe, anchored by graphql_type_element

the first declaration site’s form in merge order (the base definition’s, on a well-formed schema)

SDL description string; net-new as a persisted fact (today read live off retained graphql-java objects). Extensions cannot carry descriptions, so this is the base definition’s when one exists

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the type this site declares or extends

the site’s file; a site is a syntactic occurrence, so its location is its identity

line of the site, 1-based

in the key because a line does not identify a site: two extensions of one type can share a line in minified SDL

capture-assigned position in merge order: the base definition, then extensions in document order; on a base-less chain the first extension holds 0. Dense per type (a gate), and the order behind every element ordinal

FALSE exactly at merge_ordinal 0 on a well-formed schema; a base-less extension chain is an author error a detection reports, never a constraint

the declaration form written at this site; a mismatch against the type row’s kind is a detection

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the GraphQL type name as some declaration site spells it; the coordinate every other SDL fact hangs off

this row as graphql_element spells it, which for a type is the type name beside it; the join down from the supertype, so a reader that has a coordinate and wants its parts reads them here rather than splitting the spelling. Written by the same call that writes the supertype row and from the same string, so the two cannot disagree, and the foreign key on it is what makes a coordinate with no anchor impossible

when the reading that derived this row ran, on graphql_element.touched_at’s terms. Swept per graph and after its children, a key-to-coordinate row being what a reader joins through and so outliving nothing that still points at it. NOT NULL on graphql_element’s reasoning: a sweep that skipped unstamped rows would not be a sweep

the owning graph’s partition, anchored by store_graph; the leading key dimension that keeps one workspace’s graphs apart

the union declaring the membership, which is also the declaration this row hangs off

the type the union admits, author-spelled and unanchored: a union may name a type no document declares, which assembly refuses and this relation records

source order within the union, numbered from zero. Inherited rather than intended, and it disagrees with graphql_implements_interface.position on the base; a mapping-constant fingerprint digests a list in this order, so rebasing is a change of its own.

line of the declaration site that contributed this membership, as on graphql_field

column of the same, the site key’s fourth part

the file the member or interface token itself was written in; NOT NULL as on graphql_field

source line of that token, 1-based per the graphql-java convention

source column of that token, 1-based per the graphql-java convention

when the reading that derived this row ran, on graphql_element.touched_at’s terms: swept per graph, and NOT NULL so the sweep is total