feat: v5 relations — M:N ORM methods, orm-test package, filter type-safety + composite PK support

[pyramation]

Summary

Unified PR combining four feature branches for v5 M:N relation support. PR #863 (_meta plumbing + Clean* rename) was already merged to main; this combines the three remaining open PRs (#867, #869, #879).

1. M:N ORM add/remove methods (model-generator.ts, query-builder.ts, enrich-relations.ts, pipeline/index.ts)

• Pipeline wires tablesMeta from source.fetch() through a new enrichManyToManyRelations step that populates junction key fields on ManyToManyRelation
• Generates add<Singular>/remove<Singular> class methods on ORM models for each enriched M:N relation
• Uses getPrimaryKeyInfo() + tsTypeFromPrimitive() for correct PK typing, inflekt.singularize() for method names, existing getCreateMutationName/getDeleteMutationName utilities for naming
• buildJunctionRemoveDocument added to query-builder for composite-key junction deletion

2. Composite PK detection & delete support (infer-tables.ts, model-generator.ts, query-builder.ts)

• inferPrimaryKeyFromInputObject now returns IntrospectionInputValue[] instead of | null when multiple candidates exist
• Enables detection of composite PKs on junction tables like PostTag(postId, tagId)
• Prefers DeleteInput over UpdateInput as signal source (fewer non-PK fields)
• matchMutationOperations broadened to match deleteXxxBy* and updateXxxBy* patterns (PostGraphile generates deletePostTagByPostIdAndTagId for composite PK tables)
• buildDeleteByPkDocument takes a keys object ({ id: args.where.id } or { postId, tagId }) instead of separate id/idFieldName params — supports both single and composite PK deletes

3. Consolidated input type name derivation (utils.ts, infer-tables.ts, model-generator.ts)

• getDeleteInputTypeName(table) and getUpdateInputTypeName(table) in utils.ts now derive from actual mutation names (table.query?.delete/table.query?.update) when available, handling composite PK naming like DeletePostTagByPostIdAndTagIdInput
• New inputTypeFromMutation() helper in infer-tables.ts replaces 3 ad-hoc ucFirst(mutationName) + 'Input' calls
• model-generator.ts now calls getDeleteInputTypeName(table) instead of inline derivation (2 sites)
• 5 scattered ad-hoc derivations → 2 shared helpers. One function controls each name, one place to make a mistake.

4. Filter type-safety (input-types-generator.ts)

• buildTableFilterProperties uses the schema's {Entity}Filter input type as sole source of truth via TypeRegistry when available (same pattern as buildOrderByValues)
• Plugin-injected filter fields (bm25, tsvector, trgm, pgvector, PostGIS, connection-filter) now appear typed in generated code
• collectFilterExtraInputTypes discovers custom filter types referenced by plugin fields for generation
• Falls back to existing table.fields-based generation when TypeRegistry is absent

5. orm-test package (graphql/orm-test/)

• New test package running generated ORM models against real PostgreSQL via graphile-test
• Uses ConstructivePreset in both test suites — same preset as production, ensuring tests exercise the full plugin stack including InflektPlugin's clean M:N field names
• M:N integration tests (12 tests): seeds posts/tags/post_tags (composite PK, no surrogate id), runs full codegen pipeline, exercises ORM CRUD + junction mutations including ORM-based composite PK deletes (no raw GraphQL)
• Mega query tests (40 tests): exercises all 7 ConstructivePreset plugins (tsvector, BM25, pg_trgm, pgvector, PostGIS, connection-filter, M:N) with concrete score assertions

Updates since last revision

• Input type naming consolidated into shared helpers: getDeleteInputTypeName and getUpdateInputTypeName in utils.ts now derive from actual mutation names when table.query?.delete/table.query?.update is set. inputTypeFromMutation() helper added to infer-tables.ts. Eliminated 5 ad-hoc ucFirst(mutationName) + 'Input' scattered across infer-tables.ts (3 sites) and model-generator.ts (2 sites).
• Snapshot update: Custom mutation names now correctly derive their own input types (e.g. removeOrganization → RemoveOrganizationInput instead of DeleteOrganizationInput).

Review & Testing Checklist for Human

• Verify getDeleteInputTypeName/getUpdateInputTypeName behavioral change for existing callers — These helpers in utils.ts now consult table.query?.delete/table.query?.update. Other callers (mutations.ts, cli-generator.ts) previously always got Delete${table.name}Input. If those code paths receive tables with table.query?.delete set (e.g. composite PK tables from introspection), they'll now get the mutation-derived name. Verify this is correct or that those callers don't encounter composite-PK tables.
• Verify composite PK delete works for both single-PK and composite-PK tables — buildDeleteByPkDocument API changed from (entityName, mutation, field, id, inputType, idFieldName, select, map) to (entityName, mutation, field, keysObject, inputType, select, map). The snapshot shows single-PK tables pass { id: args.where.id }. Confirm no callers outside codegen use the old signature directly.
• Validate startsWith matching in matchMutationOperations — field.name.startsWith(${expectedDelete}By) could theoretically match unintended mutations if entity names overlap. The By suffix prevents false positives between e.g. deletePost and deletePostTag (checks deletePostBy* vs deletePostTagBy*), but verify this holds for your schema.
• Validate composite PK assumption — the fix assumes all non-clientMutationId/non-patch fields in DeleteInput are PK fields. Confirm no plugins inject extra non-PK fields into Delete input types.
• Recommended test plan: cd graphql/codegen && pnpm test (317 tests + 121 snapshots), cd graphql/query && pnpm test (18 tests), cd graphql/orm-test && pnpm test (52 tests against postgres-plus:18). Also run pnpm generate against a real schema with M:N junction tables using composite PKs and verify the generated delete methods compile and work correctly.

Notes

• pnpm-lock.yaml diff is mostly formatting changes (multi-line → single-line resolution: fields) from a pnpm version difference, plus minor version bumps (semver 7.7.3→7.7.4, pg-protocol 1.12.0→1.13.0)
• Enrichment is a no-op when tablesMeta is absent (endpoint/file sources), so all changes are backward compatible
• orm-test requires Docker PostgreSQL (CI only) — local verification limited to codegen (317/317) and query (18/18) tests
• Supersedes PRs feat: wire tablesMeta through pipeline, enrich M:N relations, add ORM add/remove junction methods #867, feat: add orm-test package — M:N + mega query integration tests against real PostgreSQL #869, fix: composite PK detection + filter type-safety from schema source of truth #879 (all consolidated here)

Link to Devin session: https://app.devin.ai/sessions/745d2d10b699452091e24131ba5edef2
Requested by: @pyramation

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🔴 updateInputTypeName is hardcoded, inconsistent with deleteInputTypeName fix

The PR correctly changed deleteInputTypeName to use getDeleteInputTypeName(table) (line 203), which derives the input type name from the actual mutation name to support composite PKs and custom mutation names. However, updateInputTypeName on line 191 is still hardcoded as `Update${typeName}Input` instead of using the analogous getUpdateInputTypeName(table). For tables with custom update mutation names (e.g., modifyOrganization), the generated code will reference UpdateOrganizationInput (which doesn't exist in the schema) instead of ModifyOrganizationInput. The snapshot at model-generator.test.ts.snap:373 confirms the bug: the Organization model's update method emits "UpdateOrganizationInput" even though the mutation is "modifyOrganization". The same issue affects composite PK tables where the mutation might be updatePostTagByPostIdAndTagId — the generated code would reference UpdatePostTagInput instead of UpdatePostTagByPostIdAndTagIdInput.

Suggested change

	const updateInputTypeName = `Update${typeName}Input`;
	const updateInputTypeName = getUpdateInputTypeName(table);

---

Was this helpful? React with 👍 or 👎 to provide feedback.