Skip to content

Handle some create and update errors in the REST adapter. #476

Merged
merged 1 commit into from Nov 20, 2012

8 participants

@pivotal-medici
  • 422 Unprocessable Entity

    Transitions the record to the invalid state. Assumes
    the server has responded with {errors: {...}} and
    sets them on the record.

  • All other status codes

    Transitions the record to the error state.

This is limited to only single, non-bulk creates/updates.

@pivotal-medici

Not sure why Travis failed there. The whole test suite works for us in the browser and from the command line.

@mspisars

It is actually failing jshint because of another commit: 90c253d
https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/serializer.js#L601
key is not defined for both the _addBelongsTo and _addHasMany

@wagenet
Ember.js member
wagenet commented Nov 15, 2012

This seems fine but I think we were planning for something more comprehensive to do error handling. Nevertheless, this might be ok in the short term. @wycats?

Also, the JSHint failure has been fixed.

@wycats
Ember.js member
wycats commented Nov 19, 2012

@elliterate if you DRY up the error callback, this looks good to go.

Evan Farrar & Ian Lesperance Handle some create and update errors in the REST adapter.
* 422 Unprocessable Entity

  Transitions the record to the invalid state. Assumes
  the server has responded with `{errors: {...}}` and
  sets them on the record.

* All other status codes

  Transitions the record to the error state.

This is limited to only single, non-bulk creates/updates.
19a963d
@pivotal-medici

The error callback is now DRY.

@tomdale
Ember.js member
tomdale commented Nov 20, 2012

programming

@tomdale tomdale merged commit 36a70c9 into emberjs:master Nov 20, 2012

1 check passed

Details default The Travis build passed
@ryanjm
ryanjm commented Apr 25, 2013

Is there plans (soon) to add support for 422 (?) on deletes? How should it be handled if an object shouldn't be allowed to be deleted?

@madadam
madadam commented Apr 25, 2013

If the object is not allowed to be deleted, wouldn't 403 be more appropriate response?

@ryanjm
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.