`isPristine` not working after `.execute()`

[velrest]

Version

"ember-changeset": "2.0.0-beta.0"

Test Case

https://ember-twiddle.com/6972ac21f4e96f14d444cbab0a52295a?openFiles=controllers.application.js%2C

Steps to reproduce

• Create a changeset of an object
• Change a value on the changeset
• Call changeset.execute()
• changeset.isPristine returns false even though the changeset and the original object have the same attributes with the same values.

Expected Behavior

isPristine is expected to return true after a .execute() since the values are applied to the model and the attributes/values should be the same.

Actual Behavior

isPristine is returns false after a .execute().

Or is isPristine meant to only be true if the changeset's changes are equal to the model's state the changeset was created on? If so the documentation is IMO a bit misleading or i simply misunderstood the concept of isPristine.

If changes present on the changeset are equal to the content's, this will return true. However, note that key/value pairs in the list of changes must all be present and equal on the content, but not necessarily vice versa:

Thanks for your work on ember-changeset!

[snewcomer]

@velrest 👋 let's start here - https://github.com/poteto/ember-changeset/pull/346

I suspect the CHANGES should be empty. In the case you are looking at, the changes object isn't. So either we need to change some logic or keep as is and modify the description of what it should represent. Based on the description, this seems like a bug!

[velrest]

If i understand the word pristine correctly, we should probably change the docs rather than the result since a changeset is pristine if the changeset is equal to the state the model was in upon the changeset's creation.

It is not pristine if a model has the same values as the changeset but the changeset was created on a model with a different state. Please correct me if im wrong as English is not my native language.

Definition of 'pristine' by google:

in its original condition

I think a new attribute like hasUnappliedChanges or something would make more sense.

What do you think?

[snewcomer]

Yeah I agree. I just added tests to show that the changeset is dirty after execute. This is because you can apply further changes to the changeset. The only thing that resets dirty or pristine state is rollback().

However, I don't think this should be the behaviour. Once you execute(), we should clear the changes and set isDirty to false. Fixing in validated-changeset