Conversation
…in where Restore polymorphic join `where` support for a select path that is stored has-many (separate value rows) in one target collection and as a single select column in another, when the targets share identical option values. Each branch is compiled per-collection with its own storage handler and unioned on the stable id/relationTo/sort projection, so the combined caller + access `where` is applied in full to every branch (no dropped or truncated constraints). Shapes that cannot be compiled soundly — text vs number scalars, differing option sets, unsupported operators — remain fail-closed. Backport of the mixed-select restoration from the oss-main change; the remaining categories (localized, array/blocks, relationship/upload/json, geo) stay fail-closed with the secure plan tracked on the oss-main PR.
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖
Largest pathsThese visualization shows top 20 largest paths in the bundle.Meta file: packages/next/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_shared.json, Out file: esbuild/exports/shared.js
Meta file: packages/richtext-lexical/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_shared.json, Out file: esbuild/exports/shared_optimized/index.js
DetailsNext to the size is how much the size has increased or decreased compared with the base branch of this PR.
|
This was referenced Sep 21, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Written by AI
Draft.
3.xbackport of #18233 — follow-up to 9339d63 (PYLD-3840). Partially restores one of the polymorphic-joinwhereshapes that 9339d63 made fail-closed. Arguably more valuable on the stable line, since it shrinks the breaking-change surface of 9339d63.What this restores
A
selectfield stored has-many (separate value rows) in one polymorphic target collection and as a single select column in another — when the targets share identical option values. This is the common case of the same logical field declaredhasManyin one collection but not another.Each branch is compiled per-collection with its own storage handler (has-many → JSON value-table subquery; single → scalar column) and unioned on the stable
id/relationTo/sortprojection, so the combined caller + accesswhereis applied in full to every branch — nothing dropped or truncated (no PYLD-3840 regression). The tworejects.toThrowmixed-shape int tests are flipped to positive filtering assertions that prove the constraint includes the authorized has-many row and excludes the unauthorized single-select row; the plan unit spec gains amixedSelectacceptance case + a differing-options rejection case.Shapes that cannot be compiled soundly stay fail-closed: text-vs-number scalars, differing option sets, unsupported operators.
Still deferred
The remaining categories (localized,
array/blocks,relationship/upload/jsontraversal, geo operators) remain fail-closed. The per-category secure implementation plan — including the text-vs-number fail-open hazard (Number('x')→NaN→null→IS NULLmatching all value-less rows) that must be guarded before it can ever be enabled — is tracked in theoss-mainPR #18233 (polymorphic-join-where-support-plan.md). It applies to3.xtoo, except3.xlacks thebuildOperatorConstraint/localeplumbingmainhas, so the localized/relationship plans there need the equivalent wiring built first.Verification
packages/drizzle/src/find): 85 passtest/joins/int.spec.ts: 114 pass / 2 skip (sqlite), 116 pass (postgres)Independently written and run against
3.x. Left as a draft for review — not for merge.Companion: #18233 (
main).