Prevent unchanged keys from being dirty

[dblythy]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

As discussed here, with the way Parse Swift handles structs, all keys are marked as .dirty in a beforeSave trigger, calling unnecessary database writes.

Feature / Enhancement Description

For efficiency, database writes should only happen if keys are updated.

Example Use Case

Updating certain keys from the ParseSwift SDK

Alternatives / Workarounds

Add a beforeSave trigger to every class to revert any unchanged keys.

Parse.Cloud.beforeSave("Object", ({object, original = new Parse.Object()}) => {
  for (const key of object.dirtyKeys()) {
    if (object.get(key) === original.get(key)) {
      object.revert(key);
    }
  }
});

3rd Party References

[parse-github-assistant]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[mtrezza]

In which other scenarios does this issue occur, other than when using the Parse Swift SDK?

[dblythy]

It also happens if you call .set without changing the value at all, I.e, setting to its currently stored value.

Similar examples are calling user.set("email", user.get("email")), which will resend a verification email.

I think if you use .dirty in cloud code, you'd expect that the value of the key is changing.

[mtrezza]

I can see scenarios in which writing a variable can trigger a script on the DB level, even if it is an unchanged value. Without evaluating these scenarios, changing the current behavior would be a breaking change, and if we decide to change it, it would have to be phased in.

Not sure whether we need to change this, because it could easily be argued that it is a developer's responsibility to not set a user's email address if the current email address is the same. For developers who are not playing in the above mentioned scenarios there is no point in doing so. It is also bad practice, because if the server determined that a key should not be set or a save operation should not be executed, then the request has already travelled a long way, usually the way with the highest cost for the user (client <-> server) in terms of latency and money.

If the server starts to overrule a decision that the developer made by calling save, we open a quite complex topic:

• What should the server respond to the client if some keys have not been saved because their value did not change or a whole save operation was not executed, because no key changed?
• Could we get into conflict with the http specification if the server responds 200 to a PATCH request despite not executing anything?
• Should the client know which fields have been updated and which not?
• Should before/afterSave be triggered if no save operation is executed?

[dblythy]

You’re right, good points. I was just looking at a server side solution to the Swift issue that can’t be fixed, but I guess this isn’t it. Thanks!