Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Feature request]: parameterized computed fields — accept arguments in orderBy/where/select

Aperta
  • Qualcosa non va?
#2,743 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
sql, typescript
Ambito
backend, database

Direzione di ricerca

The payload points at ComputedFieldsOptions (already typed (eb, ...args) => OperandExpression) and at @computed in ZModel, with orderBy/where/select as the three consumption sites. Start by finding that type and the ZModel parser/schema handling of @computed, then trace how a computed field is lowered into the Kysely query for ordering. Done means args are declared in ZModel, validated (zod, like custom procedures), serialized from the client, and accepted in all three query slots with access policies intact. Note the open named-vs-positional decision must be settled first.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Feature request: let @computed fields take arguments (so you can sort/filter by a parameterized SQL value)

What I want

Today a @computed field is a fixed SQL expression. I'd like a computed field to accept
arguments, and to pass those arguments (as plain data) when I use the field in orderBy,
where, or select.

Because the arguments are plain data, they serialize fine (JSON / superjson). So a frontend can
drive the sort/filter through the auto-generated CRUD API — no custom endpoint, no raw SQL — and
it all stays in one query with access policies and result types intact.

The problem (concrete)

A product list shows one column per "tag category". Clicking a column header should sort products by
the name of their tag in that category — e.g. string_agg(tag.name) where tag.category_id = 5.
The category id is chosen by the user at runtime.

I can't express this today:

  • Computed fields can be used in orderBy, but they take no arguments — so the runtime
    categoryId can't get in. (Categories are user data, so "one computed field per category" isn't an
    option.)
  • $qb / raw SQL can do it, but bypass access policies and lose the typed result.
  • A plugin (onKyselyQuery) can do it, but it doesn't receive the ORM arguments, so the
    categoryId has to be smuggled in via AsyncLocalStorage + hand-written SQL-AST editing.

Every workaround gives up the "one policy-checked, typed query" that the ORM is for.

Proposal

Allow a computed field to declare arguments, and pass them where the field is used.

Small example — sort users by how many posts they made since a date:

model User {
  id    Int    @id
  posts Post[]
  // a computed field that takes an argument
  recentPostCount(since: DateTime): Int @computed
}

// implementation, written once at client construction
computedFields: {
  User: {
    recentPostCount: (eb, { since }) =>
      eb.selectFrom('Post')
        .whereRef('Post.authorId', '=', eb.ref('User.id'))
        .where('Post.createdAt', '>=', since)
        .select(({ fn }) => fn.countAll<number>().as('v')),
  },
},

// usage — `args` is plain data, so this whole object can come from a client
await db.user.findMany({
  orderBy: { recentPostCount: { args: { since: '2024-01-01' }, sort: 'desc' } },
  take: 20,
});

The real use case — sort products by their tag name in a chosen category:

model ProductSite {
  id   Int          @id
  tags ProductTag[]
  tagNameInCategory(categoryId: Int): String? @computed
}

computedFields: {
  ProductSite: {
    tagNameInCategory: (eb, { categoryId }) =>
      eb.selectFrom('tag')
        .innerJoin('product_tag', 'product_tag.tag_id', 'tag.id')
        .whereRef('product_tag.product_site_id', '=', eb.ref('ProductSite.id'))
        .where('tag.category_id', '=', categoryId)
        .select(sql<string>`string_agg(tag.name, ', ' order by tag.name)`.as('v')),
  },
},

// one query, sorted in the DB, policies applied, result still typed
await db.productSite.findMany({
  where: { siteId: { in: allowedSiteIds } },
  orderBy: [
    { tagNameInCategory: { args: { categoryId: 5 }, sort: 'asc', nulls: 'last' } },
    { id: 'asc' }, // tiebreaker — composes with normal ordering
  ],
  select: { id: true, name: true },
  take: 25,
});

The same field (with args) would work in where and select too, since computed fields already
work in all three places:

await db.productSite.findMany({
  where:  { tagNameInCategory: { args: { categoryId: 5 }, not: null } },
  select: { id: true, tagNameInCategory: { args: { categoryId: 5 } } },
});

Why this shape

  • It builds on computed fields, which already evaluate in SQL and already work in
    orderBy / where / select. The only new part is "they can take arguments."
  • The arguments are plain data, so they serialize and can be sent from a client (unlike a
    function-based escape hatch — see alternatives).
  • The implementation type already looks ready for it: ComputedFieldsOptions is
    (eb, ...args) => OperandExpression, i.e. it already allows extra arguments. The missing pieces
    are the ZModel syntax for declaring the args and the query syntax for passing them.

Alternatives considered

  • orderBy.$expr — a Kysely-expression escape hatch in orderBy, mirroring the existing
    where.$expr. Good for server-built queries and nice for consistency, but $expr is a
    function, so it can't be serialized / sent from a client (the same reason where.$expr is
    server-only). It doesn't solve the frontend case. Still worth having as a server-side companion.
  • Filtered relation-aggregate orderBy, e.g.
    orderBy: { tags: { where: { categoryId: 5 }, _min: { name: 'asc' } } } — fully serializable and
    simpler, but limited to _min/_max/_count, so "sort by the tag names" becomes "sort by the
    min/max tag name". A good lightweight option, but less general than parameterized computed fields.

Notes for maintainers

  • Open question: named vs positional args. The current ComputedFieldsOptions type uses
    positional ...args; the examples above use named ({ categoryId }) for readability. Either works.
  • Args should be validated (e.g. a zod schema from the ZModel arg types), like custom procedures
    already validate their args.
  • Access policy: the computed field runs inside the main query, so the policy plugin still filters
    the queried model. The subquery's referenced tables aren't policy-checked — same as today's
    computed fields and $qb.
Lingua principale
TypeScript
Stelle
2.9k
Fork
157
Merge medio
11h 42m
PR unite (30g)
20

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di zenstackhq/zenstack

Tutte le issue di zenstackhq/zenstack

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.