-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log an assertion if the response from createRecord does not have an i… #4408
Conversation
…d and the id was not already provided by the client Closes emberjs#4346
ping @emberjs/ember-data-contributors this is ready for review. |
👍 this looks good to me! Feel free to merge - I haven't because I was wondering if this should be prefixed so it lands in beta? |
🎉 |
With this update and assertion logging, my success callback is not executed. The control flow goes instead in the error call back.
|
That behavior is intended @OmShiv. Ember Data doesn't support records from the server which don't have IDs. |
Local records without IDs created using |
@fivetanley
It fails client side, since I don't jump in success callback. Though the n/w call succeeds. Now if I set a random id, say |
Does your server return an |
none of the PUT requests in our APIs return the id. Is there a way I can set id in a serializer to the payload? |
You could set a fake ID in the serializer, but I'm a little confused on to how you would then update it later without an ID the server knows about. From the server's perspective that could be a different record. |
@fivetanley @bmac this is actually breaking. I suspect that at a minimum the assertion needs moved within the conditional, but also not all payloads return IDs, previously a null ID for a record that already knew it's ID would work, now it will not. So I also suspect this should warn with deprecation, not fail. Finally, I'm seeing situations in which although an ID is provided client side, this assertion is still triggered: it appears to be when createRecord is used to generate a record that never actually receives an ID (yes, we have those, TL;DR think a message) Working on a fix. |
Fix is being worked on here: #4544 |
…d and the id was not already provided by the client
Closes #4346