Creating a Table from a Typescript interface

[yoiang]

Hello y'all! Such a great library, it's already saving me so much headache and I can see it only getting better.

I have a naive question which I couldn't find an answer to in previous issues but forgive me if this is possible or if it has been asked and answered already but:

If we're able (and one of the first best features of Kysely is) to define a database schema using Typescript interfaces, why isn't there a way to create the tables with that schema from the Typescript interfaces that have been given?

In other words:

interface Table {
    id: GeneratedAlways<number>

    created_at: ColumnType<Date, string | undefined, never>
    metadata: JSONColumnType<any>

   ...etc etc
}

interface Database {
  table: Table
}

const db = new Kysely<Database>()

why must we then do something like

db.schema.createTable('table')
  .addColumn('id', 'number', (cb) => cb.primaryKey())
  ...etc etc
  .execute()

rather than

db.createTable('table') // it is already known to the schema so it's definition is already understood
  .execute() 

I feel this would reduce duplication and increase understandability of code, two architecture choices that seem core to kysely. I could even imagine it really simplifying migrations if it were possible!

Thanks so much for your time!

[igalklebanov]

Hey 👋

If we're able (and one of the first best features of Kysely is) to define a database schema using Typescript interfaces, why isn't there a way to create the tables with that schema from the Typescript interfaces that have been given?

TypeScript types are not expressive enough to translate to production-grade schemas. It would require building an annotation/branded type system just to express the various numeric and string data types. Lots of complexity for little to no gain.

It'd require a CLI - not gonna happen as part of core.

It is recommended to use a codegen solution instead of typing by hand.

I feel this would reduce duplication and increase understandability of code

This actually reduces the understandability of code. There's implicit stuff going on under the hood. You lose control over what SQL is being run. Kysely is a query builder, not an ORM. The main design principle is What You See Is What You Get.

Migrations should be dead simple, explicit, and should be frozen in time.

You're not forced to use Kysely's schema module or migrations. You can use Prisma/Atlas/Drizzle for migrations if you want to.

[yoiang]

Ahh right Kysely is a query builder, not an ORM, I'm sure you get this all the time, I apologize! The place that I first got turned on to Kysely even has it ambiguously labeled under ORMs alongside Prisma and others 🤣😅

[igalklebanov]

Yeah, ORM became "a library that talks to my SQL database" and everyone's confused now.