ember-data date transform: triggering change on record re-insertion about data HOT 6 CLOSED

Hi Pankaj!

Thanks for the report.

Unfortunately (for you) this is expected and has always been the case. There is no potential fix for this in the @ember-data/model paradigm. The model replacement that is under development won't provide any transforms out of the box, but its pattern for them would allow you to avoid this instability were you to implement one.

We hope to ship the replacement in 5.4, but that is still quite some time away for us.

from data.

related: #1540

from data.

Thank you for your swift and enlightening response.

I appreciate the suggestion to implement a fix for our projects, which we do intend to undertake. However, I wanted to bring to your attention that the date transform began triggering changes since the update to ember-data v4.12.0. Please note that this behaviour was not observed in the versions preceding this one. (my initial communication may not have reflected this point clearly)

Once again, thank you for your time and the insight you've provided. I (my team) looks forward to the forthcoming improvements in Version 5.4.

from data.

Please note that this behaviour was not observed in the versions preceding this one. (my initial communication may not have reflected this point clearly)

This has quite literally always been the case. hence the link to the longstanding issue from 2013 🙈

You will note the problem in that issue is exactly the same, and was never resolved for @ember-data/model.

This is for the simple reason of how transforms work with @ember-data/model, or (dare I say) don't work. The typical assumption is that transforms work by converting data into/out of another format on access by the model. However, the model does not utilize transforms at all. Instead transforms are used by some (not all) serializers to transform data between the api's format and the cache's format.

What this means is that the date transform, when used, has always been a leaky design. It results in the cache containing a Date instance. Date instances are both mutable and two instances with an identical date are not strictly equal. This means any time data is received by the cache as a Date instance it will fail a simple === check and result in a notification being sent to the model indicating the field has changed.

Why this did not occur for you in 4.11 is anyone's guess, my suspicion would be that somewhere in your app is some code that in older versions would have worked around this limitation for you, perhaps with private api usage that no longer works.

from data.

After digging some more, a year after this issue was reported here, Ember changed isEqual to compare date instances using getTime, then still another year later in 2015 a change got slid in to make the === comparison use isEqual. It was never explicitly to support dates and definitely didn't fix the underlying issue that any two objects that don't have strict identity will trigger notifications. In 4.12 as we worked to remove more of the unnecessary entanglement with Ember, we stopped using isEqual. Since date comparison was not one of the widely known features of isEqual this again went unnoticed by any except those like yourself that became dependent on it.

Generally speaking, such a notification in these cases is both safer and more desirable. In a pull base reactivity world, its unsafe to assume a non-strict comparison should go silent.

from data.