Automatically add `@updatedAt` attribute where appropriate when `prisma db pull` is run

Problem

If you have a table that looks like:

CREATE TABLE foo (update_date timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);

The Prisma schema generated by prisma db pull will be:

model foo {
  update_date DateTime  @default(now()) @db.Timestamp(0)
}

The update_date column will be set correctly when the record is created but not updated on subsequent queries. This is documented in the Prisma docs, which also identify that you can fix the issue by adding @updatedAt() in the Prisma schema. But I don’t think this is necessarily obvious enough to avoid missing it if you’re porting a large schema into Prisma and have not run into this issue before.

Suggested solution

If the column in the DB schema has the constraint ON UPDATE CURRENT_TIMESTAMP Prisma should automatically add the @updatedAt attribute to the corresponding field in the Prisma model when the database schema is pulled.

Alternatives

Additional context

We’re using MySQL 5.6 and Prisma 3.12

[hartbit]

@janpio Yes, I saw that, but we rely on db pull to prototype changes in between migrations. It’s cumbersome to remind developers to check that they do not commit the removal of the dbgenerated attribute.

[jemisonf]

These are not the same thing: ON UPDATE CURRENT_TIMESTAMP is done by the database, even when not going through Prisma, and uses the database server clock. @updatedAt is handled in Prisma, and uses the application server clock. They are not interchangeable and the introspection tool should NOT conflate them.

Thanks @hartbit this makes perfect sense!

To step back a little bit with this problem: the core issue for me is that as someone migrating to Prisma my expectation was that the contract I had in my old code (if I don’t pass in a value for updated_at when updating the record it’s automatically set to the current date according to the database clock) will continue to kept in my Prisma code without extra work on my part. You can more or less do this by adding @updatedAt to the fields (for our purposes we don’t really care about the difference between app and db clocks) but it’s not immediately obvious that that’s necessary, particularly if you’re importing a large schema, and in our case we did it only after noticing update_date wasn’t getting updated correctly for some of our records.

@janpio I’m not sure I have any good ideas for how to solve that – the best I could come up with is creating a new decoration like @dbUpdatedAt in addition to @updatedAt – but I do think it might be worth trying to come up with a solution to this issue.