We want to update our application till the latest 4.x version, but first need to update to latest 3.x version and fix all deprecations.
After update Ember from 3.26.x to 3.28.11 and Ember-Data from 3.26.x to 3.28.12, the model.deleteRecord() method does not change model.hasDirtyAttributes to be equal true. I have checked the docs and did not find that logic changed, but it did 
We have a huge application and lot of code relies on logic, that deleting a record makes its hasDirtyAttributes property equal to true, instead of it remains false. I should mention that model.isDeleted becomes equal to true after call to model.deleteRecord().
Is it expected behaviour?
I was halfway done typing that this doesnāt seem expected and you should try reproducing in a brand new app and submitting a bug report but I checked Discord and it appears that the Ember Data folk do not agree on expectations here.
You could still submit a bug report with a reproduction and argue that this is a regression but Iām not sure if that will be worth the time.
2 Likes
Hi @dknutsen . Thank you for reply. It explains what happend.
I would agree that @runspired 's explanation makes sense if logic would have been implemented like that from very beginning - no problem, but now it is not just regression, it is API change! It forces us to look through all the code base and add check for model.isDeleted.
one of the hardest things about working on EmberData is that no one (not even me) actually knows what the full observable API is. The test suite handles a lot (probably 60%) but still has blind spots, the docs handle a lot but probably only cover 20% due to emergent behaviors and composition. I think Iām aware of more than the tests and the docs but still probably missing a solid 20% of whatās possible and 20% on a project with probably tens of thousands of observable behaviors is quite a lot. So sorry for when I fail to account for something / get surprised that something was an observable behavior.
This is what I mean when I say that EmberData is subject to Hyrumās law. Itās also why I think making changes that sometimes turn out to be breaking in minorās is ok, simply because with a library with an API surface as large as EmberDataās and as many emergent behaviors from composition as it has it is literally impossible to not create a breaking change on even the smallest patch.
This isnāt to say that if breakage is revealed Iām not eager to make another patch to try to maintain behavior where it makes sense to maintain. But it is to say Iāve had to internalize that the only way to make progress is to accept that any change may break someone, and that this is ok so long as (1) Iām prepared to fix if necessary and (2) we try our best to avoid breaking too much too often.
An addendum to all this is that between not being in full control of our release cycle and also having inherited a poorly rationalized system, when we do encounter a breakage like this where it turns out the lack of good rationalization meant that something did more than we thought, we end up stuck between a rock and a hard place. We could maintain the poorly thought API for years forward, which often holds back more significant progress that is only unlocked through better rationalization, or we could see if maybe the effect on our end users is small enough theyāll work with us by addressing it on their end so that we can continue to make progress.
This was roughly the decision I made here: it seemed not many had known or relied on the behavior, meanwhile the effects of bringing the behavior back would have been significant on our ability to iterate on cache APIs. So I opted for āsorry, we brokeā once the issue was raised. To be clear, whenever I say this I am amendable to push back and debate. I say what I think is best for users and the projectās health overall, but I am but one voice. I err a little steep on the side of progress, but am very open to feedback and willing to fix to keep users moving forward as well.
I hope this turned out to not be too huge of a lift for you. But if you ended up stuck, letās chat.
1 Like
Hi @runspired, than you for wide explanation. I see your logic and it makes sense.
As for our applications we managed to do respected changes and they work as expected for months now.
