Ember Data 3.2.x + 3.3.x

Hello everyone.

There has been a trend of increasing instability in Ember Data over the last few releases. Although instability in a complicated system is not surprising, the level of stability has not been trending in the right direction. Changes will be made to address this.

Examples that come to mind include:

These issues have a common theme: they involve relationship and state code that combine complexity and underspecified behaviours.

Our high level plan for addressing this is:

  • simplify the implementation
  • express semantics more precisely
  • extend testing to real-world applications sooner

To mitigate the risks associated with adding precision to previously underspecified behaviour, we intend to add two safeguards.

Firstly, we will be testing against OSS applications in addition to Ember Data’s test suite. In particular:

Secondly, we will partner with community members to test Ember Data during its beta periods. This partnering will take several forms:

  • Private application sharing with trusted Ember Data maintainers for a limited number of apps
  • Periodic, scheduled, Ember Data upgrade sessions from the currently released version to the current beta. These sessions will be in an “office hour style” block of time.

Fixes for the most serious issues have been backported to 3.2.1 and 3.3.1. If you are upgrading now, please upgrade to 3.4.0-beta.2.

Together, we can improve things. Bug reports, minimal reproductions, and pull requests are extremely helpful, but the importance of testing our applications against betas can not be emphasized enough. Getting a tighter feedback loop is exactly what will make 3.4, the upcoming LTS release, our most successful one yet.


This kind of practical, proactive and clear communication is really awesome to see. Thank you!


Hey, I work on travis-web and I’m excited to hear about this. Let us know if there’s any way we can facilitate testing the application with betas.

I’ve actually been struggling to keep it updated with later versions because of mysterious-to-me breakage, including an Ember Data snapshot/relationship problem that I couldn’t figure out within my timebox for updating. When I have another moment, I’ll see if it’s perhaps related to the bugs you mentioned.

1 Like

This sounds great! Thanks for sharing.

1 Like

There’s a pr up for OSS external partner testing for those who want to follow this side of the implementation.

@hjdivad Is it still recommended to upgrade to the latest beta if you’re upgrading now?

@HeroicEric yes, the current 3.4 beta is 3.4.0-beta.4. I’d recommend upgrading to that version. 3.4.0 will be released very soon so upgrading to 3.4.0-beta.4 today is very nearly upgrading to 3.4.0.

1 Like

It is this behavior https://github.com/emberjs/data/issues/5575 that you experience. I think we should have released ember-data v4.0.0 for this because it needs change on all levels.

Just until Ember is changed to work with the new ember-data above v3.1.1 we need the classic behavior to fix your issue. I released ember-data-classic v3.4.0 to work around this for now. Hope it is fixed soon but the change may need Ember to change as well.

Please don’t publish forks on npm to work around issues. It’s easy for people to become confused about official packages and stability this way. npm and yarn can both install via github URLs, which works just as well without making the npm registry more confusing.

As I’d mentioned to you earlier, ember-power-select is relying on unspecified behavior, which is equivalent to relying on private API. That unspecified behavior was a bug.

There may be improvements that could be made to Ember Component lifecycle hooks (didReceiveAttrs/didUpdateAttrs) to properly trigger when an object has been dirtied, but ultimately ember-power-select should be able to fix the issue affecting you itself.

Proxies, by nature, are meant to be a stable wrapper around the content they proxy to. In the case of power-select, the library had accidentally come to rely on that proxy being torn down and re-created in situations it should not have been.

There are a few ways that power-select and/or users of power-select can resolve this:

  • use a hook that does trigger ( willRender ) and check to see if the property has changed.
  • install a computed property that watches the dependent keys appropriately.
  • resolve async relationships before passing them into the component, instead of relying on ember-power-select to unwrap the PromiseProxy
1 Like

We only needed to fork to get back the classic behavior for all our own projects and everybody who needs the classic behavior above ember-data 3.1.1 . We will try to follow the ember-data releases until this is resolved. It has in my opinion nothing to do with ember-power-select because it a breaking change without any documentation and warnings. ember-data just broke many projects without any deprecation path above version 3.1.1 It was this that will confuse more then this fork :wink:

See how to test this here

We hope a deprecation warning and upgrade path will be added soon.

I’ve been adding high level tests to ED as PRs whenever I’ve found what I thought were upgrade problems. I suggest everyone does this so that the test suite finds these issues before we do!