Relation filters and `_count` on a delegate base model give wrong results when the related model is in the same hierarchy
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- sql, typescript
- Domain
- backend-api-design, databases
Research direction
Start by reproducing the reported db.item relation-filter and _count cases, then trace SQL generation for delegate base-model relation subqueries; the issue does not name source files or tests. Compare the generated SQL with the working db.task query and check how the subquery's join to the base table affects the outer correlation. Done means the reported filters and count return the expected rows on SQLite and PostgreSQL.
Written by the indexing model from the issue text.
Description
Version
@zenstackhq/orm on dev at b51d33c4 (after 3.9.7). Same result on SQLite and PostgreSQL 17.
Summary
A relation filter or _count queried through a delegate base model gives a wrong result when the related model is a sub model of the same hierarchy. The same filter queried through the sub model is correct.
Reproduction
model Item {
id String @id @default(cuid())
itemKind String
notesAsSource Note[] @relation("NoteSource")
@@delegate(itemKind)
}
model Task extends Item {}
model Note extends Item {
sourceId String?
source Item? @relation("NoteSource", fields: [sourceId], references: [id])
}
const task = await db.task.create({ data: {} });
await db.note.create({ data: { sourceId: task.id } });
await db.item.findMany({ where: { notesAsSource: { some: {} } } }); // [] (expected: the task)
await db.item.count({ where: { notesAsSource: { some: {} } } }); // 0 (expected: 1)
await db.item.findMany({ where: { notesAsSource: { none: {} } } }); // both rows (expected: the note only)
await db.item.findMany({ include: { _count: { select: { notesAsSource: true } } } }); // task: 0 (expected: 1)
await db.task.findMany({ where: { notesAsSource: { some: {} } } }); // the task (correct)
A plain self relation without @@delegate works correctly.
Cause
This is the generated SQL for db.item.findMany({ where: { notesAsSource: { some: {} } } }) (SQLite):
select "Item"."id", ... from "Item"
left join "Task" on "Item"."id" = "Task"."id"
left join "Note" on "Item"."id" = "Note"."id"
where exists (
select 1 from "Note" as "$$t1"
left join "Item" on "$$t1"."id" = "Item"."id"
where "Item"."id" = "$$t1"."sourceId"
)
The subquery joins Note's base table as "Item" without an alias. The correlation "Item"."id" = "$$t1"."sourceId" then reads the inner "Item" (the note's own base row) instead of the outer row. So it compares the note's id with its own sourceId, which never matches.
Through db.task, the outer table is "Task", so there is no name clash and the result is correct.
This looks like the same shadowing problem that 3.9.5 fixed for access policy rules that traverse a self relation, here in the join that the delegate sub model's base table adds to a relation subquery. A possible fix is to give that join a unique alias, as the subquery already does for "$$t1".
Environment
- Node.js 24.18.0
- pnpm 10.33.0
- Dominant language
- TypeScript
- Stars
- 2.9k
- Forks
- 157
- Avg merge
- 11h 42m
- Merged PRs (30d)
- 20
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from zenstackhq/zenstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
zenstackhq/zenstack#2873 ·
Maintainers usually reply within 1 day
-
runtime
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zenstackhq/zenstack#2868 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
zenstackhq/zenstack#2694 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
zenstackhq/zenstack#2659 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
zenstackhq/zenstack#2542 · 1 comment ·
Maintainers usually reply within 1 day
All issues in zenstackhq/zenstack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
homarr-labs/dashboard-icons#2939 ·
Maintainers usually reply within 1 day
-
Agent/category reasoning variants are still checked against the stale model cache in chat.paramsOpenopencode
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
code-yeongyu/oh-my-openagent#10003 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Actions on ToastsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
nextcloud-libraries/nextcloud-dialogs#2669 ·
Maintainers usually reply within 1 day