How @updateAt should work when used in relationships

[kasir-barati]

Guys I have read #20323

And AFAIK @updatedAt operates at the Prisma ORM level. So when I had a query like this:

    const chapter = await client.chapter.update({
      where: { id: chapterId },
      data: {
        content: {
          upsert: {
            create: { content, contentHash },
            update: { content, contentHash },
          },
        },
      },
      include: { content: true },
    });

For this schema I learned that the updatedAt field of chapter record is changed while we have a new updatedAt for the chapter content record too. So in other words we are changing the updatedAt of chapter while IMO we should have done it only for chapter content record.

But I am unsure if this is really a bug and if you agree I guess I can open an issue for this as well.

[kaileyventures]

Yeah, this is expected, not a bug. @updatedat gets set on every update() call on a model, so your chapter.update() bumps the chapter's updatedAt even though the only thing in data is the nested content upsert. The content row gets its own new timestamp from the upsert, so both move.

If you only want the content timestamp to move, skip the nested write and update the content row directly. Your chapter already holds the content id, so:

const { contentId } = await client.chapter.findUniqueOrThrow({
  where: { id: chapterId },
  select: { contentId: true },
});

const content = await client.chapterContent.upsert({
  where: { id: contentId },
  create: { content, contentHash },
  update: { content, contentHash },
});

That leaves chapter.updatedAt alone. Going the other way round doesn't work either, updating a child directly never touches the parent, there's no built-in option for that yet.

[kasir-barati]

I did that already. I was just thinking that this is not semantically correct if you as me.