https://www.prisma.io/ logo
Join Slack
Powered by
Is there a way to define a DateTime field in the s...
# orm-help
e
Is there a way to define a DateTime field in the schema.prisma, so that it creates the Database Date Time with the automatic update. ie: if the Database record is updated directly in the Database, or by another mechanism than Prisma ? I have this in the schema.prisma: created_at                    DateTime                @default(now())   updated_at                    DateTime                @updatedAt   deleted_at                    DateTime? It creates this in the migration: 
createdAt
 DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),     
updatedAt
 DATETIME(3) NOT NULL,     
deletedAt
 DATETIME(3), But I need this: 
createdAt
 DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),     
updatedAt
 DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,     
deletedAt
 DATETIME(3),
j
Not right now, 
@updatedAt
is a Prisma level construct. Optimally open a feature request for this.
e
Can you point me to the link where I should do that please ?
j
e
Submitted: Enhance @updatedAt Migration output DDL #7724
👍 2
@janpio, or anyone else who can help. How can I stop the Prisma Migration from reverting Changes that I have done to Column definitions that are not supported by the Prisma DDL. ie: I need the updatedAt columns to auto update via the database, and created a Migration to make this change: eg: ALTER TABLE User MODIFY COLUMN updatedAt DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP (3) ; I did this for several tables, but now, every time I attempt to do other DDL changes in the schema.prisma, and run a DEV Migration, it creates changes in that migration.sql that will revert those changes. This is very painful, as there are many tables affected, and I would really prefer not to have to create Migrations with the --create-only flag and Hand Edit them every time. Any ideas ?
Is there an @db that I can put on those fields to set them correctly in the schema.prisma ?
j
Not that I am aware of. If Introspection can not pick it up, we can not represent it and using Migrate will unfortunately be painful.
The most doable solution is probably to write a small script that you apply on each newly generated Migration.
e
But introspection will wipe out all my comments in the file. Even if that works, it will be a lot of work to put all the comments back...
I have literally 100's of comments that are in that file ...
Also, I don't think the script will be simple, as I noticed that the Migration combined actual changes with unwanted changes on the same Tables. ie: I added a field, but it did the Add, and then in the same SQL regressed my changes to updatedAt ...
j
I did not suggest to run Introspection.
I just said that if that does not pick up a database SQL construct, Prisma does not support it properly and you will have to edit your migrations.
And yes, I am aware of the complications of that script - but it is the only workaround I can tell you about.
We are aware this situation is not perfect.
Please make sure there is an issue that the prisma Schema language should be able to support the specific construct that is not working for you.
(But I see you did that before)
e
Yeah, looks like it needs to be an addition, not a replacement for @upadatedAt ...
j
It's one of those weird MySQL only syntax things I think 😕
e
What about having an @ignore or @noupdate that creates the field if it is missing, but leaves it alone if it already exists ?
j
That would be one way. The problem here is that it is only a small part of the definition that Prisma does not understand vs. the full field. And defining that is kind of a nightmare.
14 Views
Open in Slack
PreviousNext
Powered by