Regarding belongsTo in Ember Data 1.0 beta 1

[KasperTidemann]

During the process of upgrading to Ember Data 1.0 beta 1, I've come to find that the belongsTo functionality does not work as expected - or, not as it did in Ember Data 0.13, at least. On an overall scale, here are my findings:

1) Getting associated records always return null

Say you have an App.User, an App.Address, and that they belong to each other via DS.belongsTo('address') and DS.belongsTo('user'), respectively. Then, run the following piece of code:

this.store.find('user', 1).then(function(user) {
  console.log(user.get('address'));
});

The user.get('address') part is what returns null, making it impossible to get a user's address via the user record this way even if said address has already been loaded.

• When fetching a user record, including the address in the JSON payload will indeed push it to the store, effectively preloading the associated address record - via https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/rest_adapter.js#L307 - but no gluing together of the user and address record will happen. In this case, the JSON looks like so:

  {
    "user": {
      "address_id": "2"
      "firstname": "Jazzper",
      "id": "1"
      "lastname": "Tidemann"
    },
  
    "addresses": [{
      "id": "2",
      "streetname": "1 Infinite JavaScript Loop",
      "user_id": "1"
    }]
  }
  

• When first fetching a user record via this.store.find('user', 1) and then - at some point later in time - fetching an address record via this.store.find('address', 2), the end result is the same: calling user.get('address') and/or address.get('user') will return null. Here, the JSON looks like so:

  // First request: this.store.find('user', 1);
  {
    "user": {
      "address_id": "2"
      "firstname": "Jazzper",
      "id": "1"
      "lastname": "Tidemann"
    }
  }
  
  ...
  
  // Second request: this.store.find('address', 2);
  {
    "address": {
      "id": "2"
      "streetname": "1 Infinite JavaScript Loop",
      "user_id": "1"
    }
  }
  

Note that in Ember Data 0.13, the behavior would be this:

1. If the address was not loaded previously, a call to find(App.Address, <address id>) would be made automatically, fetching the record from the server and immediately returning an empty object that would later be populated.

2. If the address record had already been loaded, it would be returned, making it possible to access its properties immediately.

2) Records referred to in templates do not update automatically

In relation to the first point, the associated record of a record referred to in a template will not update automatically.

A common pattern would be to show the user's address somewhere in a template like so:

The user lives here: {{user.address.streetname}}

However, due to the broken behavior above, this does not work, not even if you successfully load the address record related to the user record in question (either at the user record's load-time via preloading or later on).

3) Impossible to get the associated record id

To work around this, an option would be to get the id of the associated record - that is, the address_id of the user record in question. Say you have this piece of code:

this.store.find('user', 1).then(function(user) {
  console.log(user.get('address_id'));
});

Patching things up during the upgrade, getting the associated id would allow you to piece together another query for finding the address (which may really not be what you want but hey, it would work). But unfortunately, the above returns undefined when the user promise has resolved and the record has been loaded, making this strategy inapplicable as well.

Status quo:

As a result, this effectively breaks belongsTo - it simply doesn't work.

@wycats, I promised you this write-up and I'm up for helping out whenever you're available. You mentioned something regarding automatically setting up record associations in the store, right? I guess that pertains to the above.

[ralfschimmel]

I found the same behaviour, though it is by design if I am correct. You should not use _id and _ids anymore in your relations, the default behaviour now is to use the name as defined in model, thus in this case address and user instead of address_id and user_id.

See: https://github.com/emberjs/data/pull/1159/files

[KasperTidemann]

@ralfschimmel Oh my, you are right! How I could not see that is beyond comprehension. Thank you for the feedback, I'll be sure to include this in my upgrade guide + pull requests to TRANSITION.md.