Allow errors on arbitrary properties, not just defined attributes or relationships.

[alexspeller]

Addresses #1877

@tchak @igorT ping

[iwarshak]

Thanks for this @alexspeller - my pull req for this (#1979) works, but doesn't have tests and doesn't pass Travis

[alexspeller]

Oh, I didn't even see #1979 - I think the reason it failed was because forEach will fail on non-ember arrays if prototype extensions are off? Anways the approach looks basically the same in either case.

[iwarshak]

@alexspeller no worries, mine doesn't have tests. 👍

[iwarshak]

@alexspeller any thoughts on when this might get merged in?

[iwarshak]

@tchak @igorT would you mind looking at this?

[tchak]

As I already said I would like for this behavior to be optional... But if I am the only one to believe this, I suppose I will abandon my fight :)

[kurko]

I heard your argument on the original issue, but I fail to see how this would bring inconsistencies. It's the backend that enforces schemas, so I believe the client should be flexible in that regard. Nonetheless, I'd love to see the PR you promised :D

[iwarshak]

Until this gets merged in, you can add this to your app to get this functionality.

DS.Model.reopen({
    adapterDidInvalidate: function(errors) {
      var recordErrors = this.get('errors');
      for (var key in errors) {
        if (!errors.hasOwnProperty(key)) continue;
        recordErrors.add(key, errors[key]);
      }
    }
});

[ahacking]

I just commented on #1977 as I intend to fix some problems that Ember Data currently has with error handling in my project:

• mapping payload keys to model keys
• errors on embedded models

I think if the serializer is enhanced to process/extract errors and allows errors to pass through then that is all that needs to be done. It is the right place to put this concern as serializers currently control the what and how of model serialization and InvalidErrors should receive a similar treatment to other model attributes.

The adapterDidInvalidate call should just apply what the serializer has sanctioned as per what @iwarshak demonstrates above.

[igorT]

ping @tchak

[pmdarrow]

Any update on whether this is going to merged or not?

[ahacking]

IMO this should be merged.

Since PR #2392 has been merged, error payload processing is now a serializer concern. There should be no reason not to include all errors that the serializer has sanctioned.

ping @igorT, @alexspeller, @tchak

[alexspeller]

If this will be merged I will update the PR. But if it will be unmerged for another 8 months there is no point as it will have to be rebased again. So if someone on the core team does want this, please ping me when you are ready so that I can make the changes.

[tchak]

@igorT @alexspeller I am 👍 on merging this

[alexspeller]

Awesome, I will rebase shortly

[alexspeller]

@tchak rebased and tests all passing :)

[alexspeller]

@tchak @igorT ping

[bjornstar]

Can this PR get some love?