Log an assertion if the response from createRecord does not have an i…

[bmac]

…d and the id was not already provided by the client

Closes #4346

[bmac]

ping @emberjs/ember-data-contributors this is ready for review.

[pangratz]

👍 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?

[pangratz]

🎉

[OmShiv]

With this update and assertion logging, my success callback is not executed. The control flow goes instead in the error call back.

record.save().then(
   () => {
       // success callback
       // before ember-data 2.8.0
   }, 
   () => {
       // error callback
       // after ember-data 2.8.0, with EmberError log for missing id.
   }
);

[fivetanley]

That behavior is intended @OmShiv. Ember Data doesn't support records from the server which don't have IDs.

[fivetanley]

Local records without IDs created using store.createRecord are, however allowed. If you want to save them, you'll need to return an ID from the server.

[OmShiv]

@fivetanley
My APIs require a PUT for creating a record for the first time. And POST for update then onwards.
When I do:

record = store.createRecord(modelType, data);
record.save().then( ... )

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 record.set('id', 1) before the save, it works on client side without errors. But then, the updates don't work.
record.save() doesn't work thereafter, even if I manually set the id to 1 every save attempt.

[fivetanley]

Does your server return an id for the PUT request to create the record?

[OmShiv]

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?

[fivetanley]

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.

[runspired]

@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.

[runspired]

Fix is being worked on here: #4544