Skip to content
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

fields with @updatedAt are not behaving as expected #728

Closed
chrisdrackett opened this issue Jul 9, 2021 · 8 comments
Closed

fields with @updatedAt are not behaving as expected #728

chrisdrackett opened this issue Jul 9, 2021 · 8 comments
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug.
Milestone

Comments

@chrisdrackett
Copy link

  1. Prisma version (prisma -v or npx prisma -v): 2.26.0

When using prisma studio and adding records with a field that has @updatedAt I expect the item to be added with the current dateTime as the value for updated at. Instead it is getting the value 1970-01-01T00:00:00.000Z

@sam3d
Copy link

sam3d commented Jul 13, 2021

Does this behaviour occur when seeding or interacting with the normal prisma client? I've been fixing this issue by setting the @updatedAt field to also have @default(now())

model User {
  id Int @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @default(now()) @updatedAt
}

@chrisdrackett
Copy link
Author

oh, this is probably worth trying!

@sdnts
Copy link
Contributor

sdnts commented Jul 14, 2021

@chrisdrackett @sam3d That shouldn't be happening 🤔

Without Studio, you shouldn't need to add an explicit @default value to @updatedAt fields. Prisma Client should automatically handle @updatedAt field values on its own. If this isn't happening for you, you should definitely create an issue on https://github.com/prisma/prisma!

In Studio too, this is unexpected. I'll take a look!

@sdnts sdnts added bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. kind/bug A reported bug. labels Jul 14, 2021
@chrisdrackett
Copy link
Author

I figured this was a studio but because from what I can tell this works as expected in prisma itself!

@chrisdrackett
Copy link
Author

for example this is what I see when I press the Add Record button in studio:

https://cloud.drackett.com/8rnlRE/download

@sdnts
Copy link
Contributor

sdnts commented Jul 14, 2021

Ah okay, yeah that's a bug in Studio then. Will fix!

@sdnts sdnts added bug/2-confirmed Bug has been reproduced and confirmed. and removed bug/1-unconfirmed Bug should have enough information for reproduction, but confirmation has not happened yet. labels Jul 14, 2021
@sdnts sdnts added this to the 2.28.0 milestone Jul 15, 2021
@sdnts
Copy link
Contributor

sdnts commented Jul 15, 2021

This should be fixed in the latest dev version now (npm i prisma@dev @prisma.client@dev)! Fields that are marked as @updatedAt in your schema should now auto-populate with the current date & time. (If you already have a pending new record, you'll have to create a new one to observe this behaviour)

Do note that dev versions may contain unannounced breaking changes, so I wouldn't recommend using it in the long run for your app!
This will also make it to the next stable version of the Prisma CLI (Scheduled for July 27th). Let me know if this is still an issue!

@sdnts sdnts closed this as completed Jul 15, 2021
@dashmug
Copy link

dashmug commented Jan 5, 2022

The variant of this bug still exists on Prisma 3.7.0.

When you click "Add Record", the updatedAt column is prepopulated by the time when you clicked that button.

Screen Shot 2022-01-05 at 10 18 13 pm

As you edit the row and eventually save it, the row gets persisted in the DB but then the createdAt column (which is determined by the DB on write) will be later than the updatedAt.

Screen Shot 2022-01-05 at 10 18 47 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/2-confirmed Bug has been reproduced and confirmed. kind/bug A reported bug.
Projects
None yet
Development

No branches or pull requests

4 participants