Skip to content

fix(db-postgres): find custom id field from flattened fields for FK type#17123

Open
alphanull wants to merge 1 commit into
payloadcms:mainfrom
alphanull:fix/db-postgres-custom-id-in-layout-fields
Open

fix(db-postgres): find custom id field from flattened fields for FK type#17123
alphanull wants to merge 1 commit into
payloadcms:mainfrom
alphanull:fix/db-postgres-custom-id-in-layout-fields

Conversation

@alphanull

Copy link
Copy Markdown

What?

When a collection defines a custom text or number id field nested inside a layout container (row, group, collapsible, or tabs), traverseFields in @payloadcms/drizzle used a shallow Array.find on collection.fields to determine the FK column type for relationship fields.

Layout containers have no name property, so fieldAffectsData returns false for them — the nested id field is never reached, and FK columns default to integer. This causes a hard startup crash when the referenced collection uses a varchar primary key:

detail: 'Key columns "header_id" and "id" are of incompatible types: integer and character varying.'
code: '42804'

Why?

traverseFields in the Drizzle adapter needs to find the custom id field of a related collection to determine the correct FK column type. The shallow find works only when id is at the top level of fields. Any layout wrapper breaks detection.

How?

Use flattenAllFields (already exported from payload/shared) before searching for the custom id field — identical to the fix applied to db-mongodb in PR #15110 (v3.71.0). This covers all layout containers: row, group, collapsible, and tabs.

Checklist

  • Tests added (test/relationships — new customIdRowSlug collection with id nested in type: 'row', regression test verifies create/read works without FK type mismatch)
  • Existing tests pass (59 passed, 0 failed against Postgres)
  • No new dependencies

Closes #13695

When a collection defines a custom text or number id field nested inside
a layout container (row, group, collapsible, tabs), traverseFields used
a shallow Array.find on collection.fields to determine the FK column type.
Layout containers have no name property so fieldAffectsData returns false,
causing the nested id field to be skipped and FK columns to default to
integer. This caused a hard startup crash when the referenced collection
used a varchar primary key.

Fix: use flattenAllFields (already exported from payload/shared and used
for the same purpose in db-mongodb since v3.71.0) before searching for
the custom id field, matching the fix from PR payloadcms#15110.

Fixes payloadcms#13695
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Relationship with custom text id not working when field is nested in layout components

1 participant