Relation filters and `_count` on a delegate base model give wrong results when the related model is in the same hierarchy
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- sql, typescript
- Lĩnh vực
- backend-api-design, databases
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 2.9k
- Fork
- 157
- Merge trung bình
- 2 ngày 46 phút
- Pull request đã merge (30 ngày)
- 17
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của zenstackhq/zenstack
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
zenstackhq/zenstack#2873 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
`@default` on a field of a `@map`-ed enum emits the enum name as the column defaultCó thể đã có người làm @jkugsiya đã nhận 6 ngày trước. Đang mởruntime
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
zenstackhq/zenstack#2868 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
zenstackhq/zenstack#2694 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
zenstackhq/zenstack#2659 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
zenstackhq/zenstack#2542 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của zenstackhq/zenstack
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
simkimsia/netlify-axi#19 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
subhranshudash13-dotcom/Contribo#74 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement frontend good first issue Stellar Wave trivial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Godgift-care/sci-healthcare-frontend#166 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend good first issue security Stellar Wave trivial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Godgift-care/sci-healthcare-backend#171 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày