Mutable id on first request

[knownasilya]

So I have the following,

this.store.find('my-model', token);

The server returns:

{
  "myModel": {
    "id": 1
  }
}

Where the id !== token, but token will always return the same data. So this doesn't currently work, since ED sets the Model.id to the token, even after the record from the server returns.

I could do

this.store.find('my-model', { token: token })
  .then(function (model) {
    return model.get('firstObject');
  });

but is that the best way? Ultimately I always want to GET the model with the token, but PUT and DELETE by the id.

[knownasilya]

The issue is that it's a single record, so a REST call like /api/myModel/?token=2221jkh231 assumes that you could return n records, but really it's /api/myModel/2221jkh231 and there is always 1 or 0 models (404).

[bmac]

@knownasilya There has been some discussion of implementing a queryOne method #1576 would that solve your issue?

[knownasilya]

@bmac not really, since I don't know the final id, so I can't do find('my-model', id, { token: token })

[pangratz]

@knownasilya have you seen this workaround? #1576 (comment)

[ohcibi]

I just ran into the same problem. I'd say the main problem here is that the store pushes a record with an ID that doesn't exist on the server. The store should blindly accept whatever the server responded as the records ID.

Plus I think the second parameter for find should not necessarily be considered as the ID but any value, which the backend can use to find the record. The store should not do anything with that parameter, except or passing it to the backend.

[igorT]

That fails if your api does sideloading and doesn't tell you what the primary record is. Would findQueryOne work for your usecase?

[ohcibi]

findQueryOne is a shortcut for find("model", {query: "param"}).then(function(model) { return model.get("firstObject") }, so actually it works already but its a hack and not a solution.

The fact that the store pushes a record with an ID that is not an ID at all is a bug. If the backends response contained model: { id: "1", ...}, ..., the store should simply not push a record with a different ID. In fact the store should not use any parameter of find to replace any data of the backends response.

[igorT]

Well, findQueryOne isn't really a hack, because if you do a store.find('post', 1) and there is no record coming back with id:1 that promise should be rejected right?
The eager store pushing is an implementation detail, should be less obvious once the references branch is merged

[ohcibi]

Well, findQueryOne isn't really a hack

I meant that using findQueryOne to solve this problem is a hack, not the method itself.

because if you do a store.find('post', 1) and there is no record coming back with id:1 that promise should be rejected right?

Either this or it should just return an empty list - the method name is find and not findOrCreate, so actually the ID doesn't matter.. find should simply not push records. Currently the store is even pushing a record that has the exact same properties but a different ID. The situation is like this:

• this.store.find("model", "ident");
• Backend responds:

{
  "model": {
    "id": 1,
    "indexedfield": "ident",
    "otherfield": "other value"
  }
}

• store pushes an object with properties like: {id: "ident", indexedfield: "ident", other field: "other value"}

So ember-data somehow invented a new record out of nothing.

[igorT]

findQueryOne is not a hack for this particular use case.
I agree with you that creating a record upfront is a bug, and it should soon be harder to observe.
How did you observe this record in your user code btw?

[ohcibi]

How did you observe this record in your user code btw?

I'm not exactly sure what you mean. I have no observers for the record, but only computed properties

findQueryOne is not a hack for this particular use case.

agreed, lets focus on the store creating a ghost record

[wecc]

I think store.queryRecord() would solve this?

[knownasilya]

Yes sir.