Support new types from Drizzle 0.31.0

[Jonatthu]

https://github.com/drizzle-team/drizzle-orm/releases/tag/0.31.0

Prisma hasn't yet supported geometry officially, but that does not mean we cannot generate from our schema these types using this generator! :D

If somehow this is already supported by default, please let me know how to accomplish such a thing with comments on the prisma file so the generator import the right types for geometry (PostGis) and pg_vector

[fdarian]

How do you define it in Prisma? for example, for database push or migration

As long as we can identify which prisma field/type to override, I think this could be done easily. Fyi I have drizzle.custom in the pipeline to make this much easier. Maybe it could be done like

model A {
  /// drizzle.custom {
  ///   field: { func: "line", imports: [...], opts: { ... } }
  /// }
  line Int  
}

[Jonatthu]

@fdarian Yes allowing some custom fields and imports from comments on prisma to be generated down would be great, but I feel like since this is going to become a common thing it would be better something like:

// @import: import { geometry } from 'drizzle'; 
model Place {
    id                String                     @id @unique @default(dbgenerated("gen_random_uuid()")) @db.Uuid
    name              String
    // @type: geometry('geo', { type: 'point' })
    location          Unsupported("geometry")?
    @@index([location], map: "place_location_idx", type: Gist)
    @@schema("public")
}

This is just an example but maybe not the ideal api, I am not sure if you already support this actually.
From drizzle docs this is basically what we are trying to achieve to support:

[Jonatthu]

@fdarian any ideas?

[fdarian]

Hmm considering this kind of API, need a significant rewrite tho.

What do you think? @jansedlon

model Place {
    id                String                     @id @unique @default(dbgenerated("gen_random_uuid()")) @db.Uuid
    name              String
    // @type: geometry('geo', { type: 'point' })
    location          Unsupported("geometry")?
    @@index([location], map: "place_location_idx", type: Gist)
    @@schema("public")
}

[jansedlon]

@fdarian Haha I wonder if there's any downside to just shamefully allow writing javascript code for the custom type :)

---

Is there a way to report syntax / validation error via generator api?

---

If it's just a javascript in a comment it can even be parsed as an AST using existing tools (Oxc with wasm/napi bindings?) if this kind of customization and extensibility is needed. You could then infer what native imports (text, boolean, etc) are needee. If there were be imports in the comment you could place them at the top of a file. What bothers me is that there's probably too many foot guns and work hidden.

What do you think?

If this is overkill we can think of something else

[fdarian]

@jansedlon I'm considering creating a dedicated extension for this by forking the Prisma extension to add IntelliSense for pgd's directive (/// drizzle.). While this might be overkill, it aligns with my vision of making this generator the go-to solution for writing Drizzle schemas.

—

Regarding JavaScript-in-Prisma, I've attempted to make the directive as flexible as possible with the drizzle.custom directive (available since 0.7.6), but the syntax might feel too cumbersome to write. The initial syntax is even much worse, but the upside it's one line.

The drizzle.custom directive is designed to match 1:1 with Drizzle's schema definition. Field-specific configurations go under field.<config>, while other properties like $type and default can be defined at the top level.

—

To address the current use case, I could modify drizzle.custom to include a field.func option. This would accommodate both @Jonatthu's case and yours. What are your thoughts on this approach?

Alternatively, we could proceed with a one-liner syntax. The main challenge would be naming, the implementation could start with a simple string.

[Jonatthu]

@fdarian that would be great just as a temporal workaround I guess!

[Jonatthu]

@fdarian also even when I have drizzle.custom if I set Unsupported type on prisma the field gets ignored by the generator

[jansedlon]

Yeah that would be fine i guess

[fdarian]

@fdarian also even when I have drizzle.custom if I set Unsupported type on prisma the field gets ignored by the generator

I just tried generating a schema with 'Unsupported', only to find out that Prisma skipped it. I'll try migrating to a custom generator.

[Jonatthu]

Hey 👋🏼 any updates? @fdarian