Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,743 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
sql, typescript
Domain
backend, database

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from zenstackhq/zenstack

All issues in zenstackhq/zenstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.