New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting scalar list default values #8330
Comments
Thanks for bringing this up, I agree we should finally decide on how we can support defaults for scalar lists. |
Can you also try adding model Person {
emails String[] @default(dbgenerated())
} |
No dice, same error 😞 |
This one is a bit painful... We're running:
Updating migration.sql to include the default doesn't help either are seems like any prisma migrate run also generates a new migration to drop the default... Any other work arounds? |
Last sentence https://www.prisma.io/docs/concepts/components/prisma-client/working-with-fields/working-with-scalar-lists-arrays#null-values-in-arrays states:
But have been unable to use migrate without it reseting, even if I alter the table in PG itself |
Open an issue about migrations not picking that up correct please and provide all the information the issue template asks for @nicklloyd . If that is the case, it is not intended. |
Internal note: |
Problem
I'm currently migrating a schema which has a non-empty string default. My schema looks like this:
This is how it is generated from
prisma introspect
, decided from #1110. However, when runningprisma migrate dev
, the generated migration then attempts to remove the default, generating:Removing this and attempting to add a default using
dbgenerated
leads to the following error:Suggested solution
As far as I can tell, this error is entirely artificial at this point because the release of 2.16.0 introduced a workable syntax for scalar lists via
dbgenerated
. I'd like to propose simply removing this check:https://github.com/prisma/prisma-engines/blob/215319b1f112e9e5b5a1f2d2b0553982d2669776/libs/datamodel/core/src/transform/ast_to_dml/db/attributes.rs#L320-L322
Alternatives
None considered, as I haven't found any drawbacks to this proposal.
Additional context
The text was updated successfully, but these errors were encountered: