Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Relation filters and `_count` on a delegate base model give wrong results when the related model is in the same hierarchy

オープン
  • 何か問題がありますか？
#2,870 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
sql, typescript
領域
backend-api-design, databases

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
TypeScript
スター
2.9k
フォーク
157
平均マージ
11時間 42分
マージ済み PR（30日）
20

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

zenstackhq/zenstack のほかの issue

zenstackhq/zenstack の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。