Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,870 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
sql, typescript
Área
backend-api-design, databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
TypeScript
Estrellas
2.9k
Forks
157
Merge medio
2 d 46 min
PR fusionados (30 d)
17

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de zenstackhq/zenstack

Todos los issues de zenstackhq/zenstack

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.