If I use two different attributes to load a record, it gets materialized as two different records, instead of one

[darthdeus]

Given a server implementation that looks like this

def show
  respond_with User.find_by_username_or_id(params[:id])
end

If I do App.store.find(1) which makes a request GET /users/1 and returns

{
  id: 1,
  username: "johndoe"
}

and then I do App.store.find("johndoe") which makes a request GET /users/johndoe and returns the same JSON, the result is that now I have two different users stored in the identity map.

This is because Ember Data will store the initial ID used to query, even if it is different from the one returned by the server.

I'm not sure if this is intentional (probably not), because Ember already knows which attribute is the primary key. It should either use that in the identity map, or raise an exception that the record which was returned has a different primary key than the one which was used to query, because of this exact scenario.

This becomes an issue when I want to transition to a route which shows that user, it will look like /users/johndoe, and if I try to query the user's ID attribute, it returns the username.

user = App.User.find("johndoe") // returns { id: 1, username: "johndoe" }
user.get("id") // => "johndoe"

[mikegrassotti]

👍

[raila]

user = App.User.find("johndoe") --> find() thinks "johndoe" is the id!
calling App.User.find(id) always interpretes the provided string as an id.
You would have to call App.User.find({username: "johndoe"}) which uses findQuery internally.

At least that is how I understand the inner workings of the find() method.

[darthdeus]

@raila you can't do that, because findQuery returns an array of results, not a single record. See #551 for more detail

[seanabrahams]

👍

[kevinansfield]

Did you ever find a solution to this? I'm running into a lot of issues with duplicate records in the identity map and having to work around that all over the place because of this.

[Globegitter]

Is there any advancement/update on this?

[wagenet]

#551 addresses this better.