DS.Model ID as string causes error?

In older versions of Ember and Ember Data a model ID could be a string, when passed from the server. With some changes I’m making to my app now, it seems as if that’s no longer the case?

The Set Up

Ember: 1.3.0-beta.1+canary.ea261c9f
Ember Data: 1.0.0-beta.2
Handlebars: 1.0.0
jQuery: 2.0.3 

When my route loads, I’m grabbing an account from the server:


    username: "HallOatesFan",
    interactions: [
    messages: [

Social.Account = DS.Model.extend({
    username: DS.attr("string"),
    messages: DS.hasMany("message"),
    interactions: DS.hasMany("interaction"),

Social.Message = DS.Model.extend({
    text: DS.attr("string"),
    account: DS.belongsTo("account"),

Social.Interaction = DS.Model.extend({
    native_id: DS.attr("string"),
    account: DS.belongsTo("account"),

The Problem

If the interactions array on the account model is empty, Ember fires a request to get messages, then loads them into the page.

/api/1/accounts/10001262/messages/ // returns an array of objects

However, when I try to do the VERY same thing for interactions, I get an error:

Assertion failed: You must include an `id` in a hash passed to `push`
Assertion failed: Cannot call get with 'isEmpty' on an undefined object.

And Ember never even tries to load the interactions endpoint.

From past experience I know this is because Ember doesn’t have an ID to associate with the record. If I return a dummy number in the interactions array from the accounts endpoint, Ember remains happy.

Is this a change that has been made to Ember Data? I’m almost positive that Ember previously allowed string IDs. I’d really love some guidance.

Just a quick update -this might be 100% related to the ember-data adapter you are using :slight_smile:

right now we only support int like ids but as you stated, previously it had support for the guid like ids

This might be better as a pull request / issue on github

Yep. Toran is right. This was caused by the Adapter we’re using.

@toranb Is strings as ids not supported now? i need that support for my project. what could be the issues i might hit if i use strings as ids.

now string ids(v1.0.0-beta.5) might work, as the code is coercing to string before building/finding records.

Great question- I’m honestly not sure as I don’t use a custom string based id. Since 1.0.0 beta 5 supports it, I think it should work with a few tweaks to my django adapter (if you do a find for “pk” in the source code you will see that we have a few places we hard-coded “id” instead of “pk”).

If you want to dig in and verify it works/ or doesn’t let me know. It would be a great PR to submit if you have the bandwidth :slight_smile: