feat: _meta plumbing + ManyToManyRelation junction key fields + Clean* rename#863
feat: _meta plumbing + ManyToManyRelation junction key fields + Clean* rename#863pyramation merged 3 commits intomainfrom
Conversation
- Extend CleanManyToManyRelation with junctionLeftKeyFields, junctionRightKeyFields, leftKeyFields, rightKeyFields (both codegen and query packages) - Add MetaTableInfo type to SchemaSourceResult for _meta data flow - Add fetchGraphqlQuery() helper for arbitrary GraphQL queries - Endpoint source now fetches _meta in parallel with introspection (graceful fallback if endpoint lacks MetaSchemaPlugin) - Add buildSchemaWithMeta() to graphile-schema that returns SDL + cached tablesMeta from MetaSchemaPlugin - Database source now returns tablesMeta via buildSchemaWithMeta() Sets up the plumbing for PR 3 (ORM add/remove junction methods).
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
…ablesMeta directly Reverted all HTTP plumbing (fetchGraphqlQuery, parallel _meta fetch in endpoint.ts) and the buildSchemaWithMeta refactor. Instead, database.ts just snapshots _cachedTablesMeta (already populated by MetaSchemaPlugin during buildSchemaSDL).
…Relation, etc.) Mechanical rename across 57 files. The Clean* prefix was meaningless noise — these types are already scoped to the codegen/query context. CleanTable → Table, CleanField → Field, CleanFieldType → FieldType, CleanRelations → Relations, CleanBelongsToRelation → BelongsToRelation, CleanHasOneRelation → HasOneRelation, CleanHasManyRelation → HasManyRelation, CleanManyToManyRelation → ManyToManyRelation, CleanOperation → Operation, CleanArgument → Argument, CleanTypeRef → TypeRef, CleanObjectField → ObjectField
devin-ai-integration
bot
changed the title
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| return { | ||
| introspection, | ||
| tablesMeta: [..._cachedTablesMeta] as MetaTableInfo[], | ||
| }; |
There was a problem hiding this comment.
🟡 tablesMeta collected from _cachedTablesMeta but never consumed by the pipeline
The DatabaseSchemaSource.fetch() now collects tablesMeta from the _cachedTablesMeta global (line 136) and returns it in SchemaSourceResult. However, the only consumer of source.fetch() is runCodegenPipeline() at graphql/codegen/src/core/pipeline/index.ts:115, which destructures only { introspection }, completely discarding tablesMeta. This means the new ManyToManyRelation junction key fields (junctionLeftKeyFields, junctionRightKeyFields, leftKeyFields, rightKeyFields) added to graphql/codegen/src/types/schema.ts:195-202 and graphql/query/src/types/schema.ts:195-202 will never be populated on the inferred tables. The entire _cachedTablesMeta integration is dead code — the data is collected, returned, and silently dropped.
Prompt for agents
The tablesMeta is returned from DatabaseSchemaSource.fetch() but never consumed. In graphql/codegen/src/core/pipeline/index.ts at line 115, change the destructuring from `const { introspection } = await source.fetch()` to `const { introspection, tablesMeta } = await source.fetch()`, then pass tablesMeta into inferTablesFromIntrospection or add a post-processing step that enriches the inferred ManyToManyRelation entries with the junction key field information from tablesMeta. Without this wiring, the new junctionLeftKeyFields/junctionRightKeyFields/leftKeyFields/rightKeyFields on ManyToManyRelation will always be undefined.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
Two changes:
1. Rename
Clean*types → drop prefix (57 files, zero logic changes)All 12
Clean*interfaces ingraphql/codegenandgraphql/queryrenamed to plain names:CleanTable→Table,CleanField→Field,CleanManyToManyRelation→ManyToManyRelation, etc.Mechanical find-and-replace. The
Cleanprefix was meaningless — these types are already scoped to the codegen/query context.2.
_metatable metadata plumbing for M:N junction key fieldsAfter
buildSchemaSDL()runs, the MetaSchemaPlugin has already populated_cachedTablesMetawith M:N relation metadata. We just snapshot it:graphile-schema/src/index.ts— re-exports_cachedTablesMetafromgraphile-settings(1 line)database.ts— snapshots[..._cachedTablesMeta]afterbuildSchemaSDL()and returns it astablesMetasource/types.ts— addsMetaTableInfotype + optionaltablesMetafield onSchemaSourceResultManyToManyRelation— extended withjunctionLeftKeyFields,junctionRightKeyFields,leftKeyFields,rightKeyFieldsNo new functions. No HTTP code. Just uses what's already there. PR 3 will consume these fields for ORM add/remove junction methods.
Review & Testing Checklist for Human
Clean*type names are exported from@constructive-io/graphql-codegenand@constructive-io/graphql-query. Any external consumers importingCleanTable,CleanField, etc. will break. Consider whether type aliases are needed for backward compat.unknown[]→MetaTableInfo[]cast indatabase.ts: Structurally compatible (subset), but skips runtime validation. VerifyjunctionLeftKeyAttributesetc. exist on the cached objects.transformFieldToCleanOperationstill reference "Clean" in their names. Minor inconsistency — they're private, but worth a follow-up cleanup.Test plan: Run codegen in database mode against a schema with M:N relations. Verify
tablesMetais populated onSchemaSourceResult.Notes
endpoint.ts,file.ts,pgpm-module.tssources unchanged — they return{ introspection }withouttablesMeta(field is optional)tablesMetaor the new key fields yet — plumbing only. PR 3 adds consumers.Link to Devin session: https://app.devin.ai/sessions/745d2d10b699452091e24131ba5edef2
Requested by: @pyramation