We've found that after saving a Backbone.js model the generated properties (_acl, _kmd) are detected as newly changed. This can cause some issues if you are later checking for changed status on a model (via hasChanged or changedAttributes methods). If you save the model again, _kmd will of course always change and therefore show up as a changed attribute.



Is there a downside to having these generated properties be set silently on the Backbone model after saving, preventing them from showing up as changed attributes? If not, is this something that would be considered in future updates?

I can’t think of a downside. I am not sure if Backbone provides a way to only silence certain attributes. If there is, I can certainly include this in a future release.

Fairly certain Backbone on it's own doesn't provide this. The way most people handle it is by performing a model set on an arbitrary property using the same exact value it's already set to, and pass an option for silent = true. Since changed attributes only reflect what was actually changed in the last set, then changed attributes are effectively reset and hasChanged() returns false.



So something like:

model.set({property: model.get('property')},{silent: true})

In that case, it seems best to leave the default behavior in place for the sake of clarity. There might be use cases where changes on acl and kmd need to be listened to (e.g. (re)sorting a list by date). Seems your approach would work well if you don’t want this event.

I see where you are coming from, my only comment would be that these are automatically set attributes and unexpected for most users. Basically without using the workaround I mentioned about, hasChanged will *always* return true when creating/saving a model. This could cause issues that are hard to debug for users who aren't expecting this, and instead expecting changed attributes to function just fine.



I guess at the least, maybe a comment in the documentation would be helpful.