mongoose: wrongly update timestamps on updateOne

Prerequisites

I have written a descriptive issue title
I have searched existing issues to ensure the bug has not already been reported

Mongoose version

8.0.4

Node.js version

MongoDB server version

6.0.6

Typescript version (if applicable)

No response

Description

Hi,

When updating a doc for a schema that includes the { timestamp: true } option, I’ve noticed that even when no updated fields are found, the updatedAt field still gets updated.

In my opinion, this shouldn’t be the case since the doc are not updated. Same things when updating the doc when the fields have the same values as the original ones.

Disabling timestamps is not an option in this particular update, since most of the time the update does in fact really update the doc with new fields. Thank you

Steps to Reproduce

const mongoose = require("mongoose");

const eventSchema = new mongoose.Schema(
  { url: String, city: String },
  { timestamps: true }
);

const Event = mongoose.model("Event", eventSchema);

async function run() {
  await mongoose.connect("mongodb://localhost:27017");

  await Event.create({ url: "google.com" });

  const res = await Event.updateOne({ url: "google.com" }, { $set: { url: "google.com" } });
  console.log(res); // should not show  { modifiedCount: 1 }, neither update updateAt field,  { timestamp: false } is not an solution
  
  const res = await Event.updateOne({ url: "google.com" }, { $set: { url: "yahoo.com" } });
  console.log(res); // this is OK to update updatedAt field since the docs is in fact updated
}

run();

Expected Behavior

No response

About this issue

Original URL
State: open
Created 6 months ago
Comments: 19 (5 by maintainers)

Most upvoted comments

I agree with the notion that when a document is updated with information that’s the same as the current information, we should not update the timestamp, I can understand why we would be doing that in the case of Document#save(...) since we already know the exact document and the exact existing data.
For the scenario of Model.updateOne({ _id: user._id }, {});, I think we could, and should save the DB call and make it a no-op (as long as upsert is not true) since the update object could be programmatically constructed, and sometimes the update object will be empty.
However, for the scenario of User.updateOne({ url: "google.com" }, { url: "google.com" });, while it’s technically possible for this particular scenario to infer that it’s a no-op, it’ll open the door for more complex scenarios where it’s not possible to infer that change, such as User.updateOne({ url: { $in: ["google.com", "youtube.com"] } }, { url: "google.com }); In this scenario the url value could be the same and could be different, and we’d be updating the timestamp anyway. Which is why I think we should just be consistent and update the timestamp as long as we’re sending an update command. If we’re not sending an update command at all (empty $set), then it makes sense to not update the timestamps at all.

What do you think everyone?

AbdelrahmanHafez on Feb 13, 2024

To some extent, the “right” answer here depends on your use case for performing updates. Imagine a situation where you’re keeping a document synced up with an external system’s data. You would want updatedAt to change even if no properties in the underlying document actually changed, since updatedAt reflects how recently the document has been synced to the external system (i.e., how stale the data is). If you run a daily sync cron job, but the data never changes, updatedAt tells you the last time the job ran successfully.

I see both sides, but ultimately it feels cleaner to maintain existing behavior because updatedAt is easier to reason about when it simply means “executed a Mongo update command”. It’s a separate discussion about optimizing the Mongoose wrapper around update commands to detect when the update query itself is empty and aborting the update in that event.

Ultimately seems like this issue is more about a theoretical “changedAt” property, which explicitly is about changes.

sderrow on Feb 26, 2024

i also agree with @AbdelrahmanHafez, as in that as long as a command is send we should update the updatedAt. i also agree with maybe saving the empty update call (provided that options dont change it). though maybe such a change should either be done behind a option or in a major update.

hasezoey on Feb 14, 2024

In my opinion it makes sense to update the timestamp, as we have called an update on the document, no matter if it’s the same data it had before; And I think most of the developers are used to see this as updated. So I don’t suggest changing it as many developers are using this feature with this mindset.

Imanghvs on Feb 9, 2024

What I tried doing was making a pre schema for updateOne and checking if city and url were null, undefined or empty string , or check that they equal the current url/city. If so, then keep the update.updatedAt = this.updatedAt.

eventSchema.pre('updateOne', async function(){
  const update = this.getUpdate()
  console.log(update.url)
  console.log(update.city)
  if (((update.url === undefined || update.url === null || update.url === "") ||
      (update.city === undefined || update.city === null || update.city === "")) || (
        (update.url === this.url) || (update.city === this.city)
      ))
  {
    update.updatedAt = this.updatedAt
  }

  console.log(update.updatedAt)
})


const res = await Event.updateOne({ url: "google.com" }, { $set: {} });


  const res = await Event.updateOne({ url: "google.com" }, { $set: { url: "google.com" } });

  console.log(res); //modifiedCount: 0

  const res2 = await Event.updateOne({ url: "google.com" }, { $set: { url: "yahoo.com" } });

  console.log(res2); //modifiedCount: 1

  const res3 = await Event.updateOne({ url: "google.com" }, { $set: { }});

  console.log(res3); //modifiedCount: 0

donoftime2018 on Jan 13, 2024

If you read the docs, this keeps the timestamps for the schema, but skips the timestamp for the update query.

donoftime2018 on Jan 13, 2024