Corey

> As I've said previously, I think this should be a consideration developers should be aware of, especially if they use cloud functions. Agreed, they should definitely be made aware...

> If this is the case, I think we should mitigate the dirtyKeys on the server to minimise the potential confusion with cloud code, or unpredictable consequences of internal read-only...

I see your server PR, makes sense and my guess is the trade off will be negligible when compared to the DB writes. The server does a lot of key...

I think the PR I just opened with respect to this issue solves this problem and makes it pretty easy for the developer, server, and cloud code to handle dirty...

> What are the risks for the developer when using emptyObject? I assume the risks mentioned in previous comments have not been eliminated. what risk has emptyObject not eliminated?

> My understanding is that if a developer uses `emptyObject`, they still need to compare the updated fields to the fields on fetch. > > E.g, > > 1. object...

> I am referring to the [comments](https://github.com/parse-community/Parse-Swift/issues/242#issuecomment-925444819) against offering a mutable object. If the Parse SDK is now offering a way for a developer to implement this, do the arguments...

> > The Swift SDK doesn't work like this. If a developer is "enumerating through keys" > > in the first example you showed, you set the required fields to...

> Purely from an optimisation perspective, I don’t understand where a developer wouldn’t need dirty. This is using the mindset of the old SDKs which this SDK doesn't follow. In...

> From reading this and flovimart's thread I don't understand yet what the specific technical constraint are that do not allow the SDK to have a fully functional dirty implementation....