REST server must echo back `clientId` on create action.

[jimsynz]

While implementing a feature with EPF I was having trouble with my model's ID not being updated from the server after a successful POST. eg:

var user = session.create('user');
user.set('name', 'Marty McFly');
session.flush().then(function(models) {
  console.log("Created user with ID " + user.get('id'));
});

Was resulting in Created user with ID undefined in he browser console. After some digging I realised that EPF was expecting my server to echo back the clientId in the JSON payload.

It should be safe to assume that when you create a resource on an API endpoint and the server responds with a single resource payload then we should use that as the server's representation of the resource? Keen on your opinion @ghempton - if you agree then I'll start working on a PR.

[ghempton]

I agree that EPF needs to do a way better job inferring that a model is the context of a particular request without the clientId being sent back. The serialization code was recently refactored and hopefully I will clean this up soon.

[dev-inigmas]

I recently got the following when attempting to save a new record:

Error: Assertion Failed: clientId has changed for <SO.Edge:ember6035:[null, edge540]>

Is it related to this?

[ghempton]

Are you echoing clientIds and does the Edge model have an Id? I suspect Edge might not have id (is it embedded?) causing it to think that the model with id of null has received a different clientId.

Feel free to add me (ghempton@gmail.com) to google talk for real-time support.

[dev-inigmas]

The Edge model does indeed have an id. It would be the parent document for two types of sub-documents.

[ghempton]

Hmm so this error arises when server sends back a clientId for a model with a particular id that is different for the clientId on the client corresponding to that id.

[dev-inigmas]

I'm going to spend a little more time investigating what's going on in my code base.

[dev-inigmas]

Hmm....I had thought last night that I was able to create new Races without a problem. I guess I was just distracted by the uncaught exception issue...

[dev-inigmas]

So, it seems like I can create new records that don't have embedded documents just fine. And, if I don't add any embedded documents to a record, then they'll save appropriately as well.

[dev-inigmas]

I put some print outs in the id_manager and got the following:

CLIENT_ID:   race27 deps.js:74404
EXISTING_ID: race30 deps.js:74405
Reason: Error: Assertion Failed: clientId has changed for <SO.Race:ember2007:[null, race27]>

The POST from the client, looks like this:

{
  "race": {
    "id":null,
    "client_id":"race27",
    "client_rev":1,
    "name":"qwe",
    "description":"qwe",
    "module_id":"53c050319700005e2157aa20",
    "abilities": [{
      "id":null,
      "client_id":"race_ability28",
      "client_rev":1,
      "ability":"qwe",
      "description":"qwe",
      "script":null,
      "race_id":null
    }]
  }
}

The "response" (after my parent/id injection takes place), looks like this:

{
  "doc_meta": {
    "created": 1405115840129,
    "updated": 1405115840129,
    "created_by": "53bd768f970000004057a9f4"
  },
  "id": "53c05dc09700006f9157aa29",
  "name": "qwe",
  "description": "qwe",
  "abilities": [
    {
      "ability": "qwe",
      "description": "qwe",
      "race_id": "53c05dc09700006f9157aa29",
      "id": "race_ability-53c05dc09700006f9157aa29-0"
    }
  ],
  "module_id": "53c050319700005e2157aa20"
}

[ghempton]

Hmm that seems weird. Can you try to "pass-through" the clientId that is sent from the client back up to the client.

This is needed so that epf knows that the created children are the same ones that were created on the client.

On Fri, Jul 11, 2014 at 3:14 PM, David Patrick notifications@github.com wrote:

I put some print outs in the id_manager and got the following:

CLIENT_ID: race27 deps.js:74404 EXISTING_ID: race30 deps.js:74405 Reason: Error: Assertion Failed: clientId has changed for <SO.Race:ember2007:[null, race27]>

The POST from the client, looks like this:

{ "race": { "id":null, "client_id":"race27", "client_rev":1, "name":"qwe", "description":"qwe", "module_id":"53c050319700005e2157aa20", "abilities": [{ "id":null, "client_id":"race_ability28", "client_rev":1, "ability":"qwe", "description":"qwe", "script":null, "race_id":null }] } }

The "response" (after my parent/id injection takes place), looks like this:

{ "doc_meta": { "created": 1405115840129, "updated": 1405115840129, "created_by": "53bd768f970000004057a9f4" }, "id": "53c05dc09700006f9157aa29", "name": "qwe", "description": "qwe", "abilities": [ { "ability": "qwe", "description": "qwe", "race_id": "53c05dc09700006f9157aa29", "id": "race_ability-53c05dc09700006f9157aa29-0" } ], "module_id": "53c050319700005e2157aa20" }

— Reply to this email directly or view it on GitHub https://github.com/getoutreach/epf/issues/76#issuecomment-48789092.

Gordon L. Hempton http://codebrief.com 360.460.8098

[dev-inigmas]

Yeah.... I was really hoping that was an optional requirement.

[dev-inigmas]

Okay.... Passing back the clientId appears to be working. It seems to me then that this ticket does represent a current issue for EPF. At least for Models with embedded documents.

Thanks for all the help.