Infer reverse table relationship for ad-hoc queries (when not declared in schema)

[kriszyp]

Investigative — needs design. A relationship declared in only one direction (e.g. Challenge.questions: [Question] @relationship(to: "challengeId") without an inverse Question.challenge) is invisible from the other side. Enable ad-hoc queries to traverse the inverse direction without requiring the user to declare it explicitly.

Example schema

type Challenge @table @export {
  id: Int @primaryKey
  questions: [Question] @relationship(to: "challengeId")
}

type Question @table {
  id: Int @primaryKey
  challengeId: Int @indexed
}

A user wanting to query "for this Question, what Challenge does it belong to?" today must explicitly declare the inverse.

Why this isn't a slam-dunk

From the Jira discussion (Kris): "It seems like this requires a lot of assumptions about how the inverse relationship should work, what the name is, and if the user even wants it to be exposed."

Open design questions:

• Naming: what name should the inferred inverse field take? challenge (singular of source type)? Challenge? Customizable?
• Cardinality: the original [Question] declares many-from-one. The inverse is always one-from-one (by primary key) — but does the user want it exposed at all?
• Privacy/exposure: declared relationships are explicit user intent. Auto-exposing them changes the API surface without user opt-in. Could break schemas with sensitive cross-table data.
• Ad-hoc only? Devin suggested ("Maybe if you're explicitly asking for it somehow in the search?") an opt-in path: only resolve the inverse when the query explicitly asks for it (e.g. a flag in search_by_conditions), so the schema's exported surface is unchanged.

To investigate

• Sketch the explicit-opt-in version (Devin's suggestion). What does the search syntax look like?
• For SQL (where joins are inherently ad-hoc), does the AlaSQL path already handle this if the foreign key is @indexed? If so, the gap is specifically the operations-API / GraphQL exposure.
• Decide whether this is even worth the design churn given the workaround is "declare the inverse in your schema" (a single-line GraphQL change).

Not Ready

Until a concrete syntax + semantics proposal exists. Low priority per Jira.

---

Tracked in Jira: CORE-3032

🤖 Filed by Claude on behalf of Kris.