Survey: Why does your project use dbgenerated() (with no string parameter)?

[janpio]

A long time ago, Prisma used the @default value/function dbgenerated() to represent default values that could not be expressed in @default directly.
Later we added a string parameter to the dbgenerated() function, so you can now actually define whatever should be put into the DEFAULT value in the generated migration. We also updated Prisma's Introspection to use @default(dbgenerated("...")) when encountering default values that do not fit into @default directly.
Since then dbgenerated() is technically not necessary any more in Prisma.

We are now thinking about removing dbgenerated() as a valid value of @default and make it a Schema validation error instead in a future version of Prisma. Of course, we do not want to cause unneeded work and trouble for users that currently still have dbgenerated() in their Prisma schema, and hence are asking you for feedback if your project is currently still using dbgenerated():

1. Did Prisma Introspection (prisma db pull) create a schema with @default(dbgenerated()) for your database? If so, please answer with the relevant snippet of your Prisma schema and also the underlying database SQL schema. Does it still happen with recent Prisma versions (4.16.2 and up)?
2. Did you write your schema with dbgenerated() manually? If so, please answer with why you chose to not define the actual default value for the field or use dbgenerated with a string parameter. Does Prisma Introspection (prisma db pull) overwrite the empty dbgenerated() with a more useful value for you? Can you cleanly run migrations afterwards?
3. Are you using dbgenerated() for some other reason? Please comment and explain below.

Thanks!

[nejsimon]

Hello!

We are using dbgenerated() for a few columns that are generated at the database level in postgres.

The columns are created with something like:
ALTER TABLE "foo" ADD COLUMN "bar" TEXT GENERATED ALWAYS AS ( ...expression... ) STORED;

Schema looks like this:
bar String? @default(dbgenerated())

Since it's done at the db level the data is guaranteed consistent, you don't have to manually calculate the value when retrieving data and you can use it like any column i.e. order by without using $rawQuery.

They use dbgenerated() because otherwise prisma wants a value for this column when creating an entity. Making then nullable would be an option but then the typescript type will contain null as a possble value that they will never actually have but you still must check for just to make typescript happy.

So using @Default(dbgenerated()) solves this case.

If I run prisma db pull it generates something like this:
bar String? @default(dbgenerated(" ...expression... "))

But this is not the same as the above as it will only set the value once.