Skip to content

Add standard-schema powered query result parsing plugin. #1856

Description

@igalklebanov

Hey 👋

This has been requested since the early days. Personally, I feel this might be redundant in 99.999% of cases, but there are probably some cases where this could help cover blindspots and help ship complex dynamic/composed queries confidently.

Another benefit is with narrowing the output type via a standard schema instead of manually with $narrowType and maybe lying to the compiler and to downstream if things don't align at runtime. Think of, narrowing and validating that what looks like a regular string in codegen, is actually an application-side enum value.

Another benefit is result transformation in-chain, e.g. hydrating that string result column to a native Date.

It needs to yell at you when you pass a schema where its input type doesn't match the query's output type.

It needs to support standard-schema, not a specific library, not zod-specific. It should not add a non-dev dependency. It should not require consumers to install a standard-schema package.

It could look like (please don't use it for such a simple query!!!):

import { z } from 'zod'

enum PersonStatus {
  ALIVE = 'alive',
  DEAD = 'dead',
  IN_COMA = 'in_coma'
}

const personSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  createdAt: z.string().transform((value) => new Date(value)),
  status: z.nativeEnum(PersonStatus),
})

const results = db
  .selectFrom('person')
  .selectAll() // output type is { id: string; email: string; createdAt: string; status: string; }[]
  .$parse(personSchema) // output type is { id: string; email: string; createdAt: Date; status: PersonStatus; }
  .execute()

Should we do it? is it the responsibility of a query builder? Unclear.

I don't like the part where people will overuse it for even the simplest queries that don't need any schema, and not only for specific transformations and narrowing use cases.

I don't like that it might give people the wrong idea about type-level safety, and will make some maximalist redditors falsly think that Kysely is not type-safe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    apiRelated to library's APIbuilt-in pluginRelated to a built-in pluginenhancementNew feature or requesttypescriptRelated to Typescript

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions