hasMany Relationships and waiting for all child models to be loaded

1

I have a very basic nested route set up that was working prior to the new release with a fixture adapter. this.resource(‘parent’, {path: ‘/parent/:parent_id’}, function(){ this.resource(‘child’, function(){ this.route(‘nestedChild’);

The parent model has several hasMany relationships which I attempt to render into the template of the nested child.

I have a transitionTo(nestedChild, parentModel) which because of the route hiearchy has the argument passed to the parentRoute object first, where I set it in the setUpController hook.

App.ParentRoute setupController: function(controller, model){ controller.set(‘model’, model); }

then in the nestedChild route I set the model by using controllerFor

App.NestedChildRoute setupController: function(controller, model){ controller.set(‘model’, this.controllerFor(‘member’).get(‘model’)); }

When I transition using the transitionTo I get the following error message,

Assertion failed: You looked up the ‘CheckingAccounts’ relationship on ‘Www.Member:ember317:1’ but some of the associated records were not loaded. Either make sure they are all loaded together with the parent record, or specify that the relationship is async (DS.attr({ async: true })) components.js:9587

Uncaught TypeError: Cannot read property ‘resolve’ of undefined

I tried making the hasMany’s asynch as suggested but the behaviour becomes unpredictable where sometimes the view renders perfectly and others it errors out and only renders upon refresh.

How can I “make sure they are all loaded together with the parent record” to solve this issue, or is this even the right approach?

2 Likes
2

using { async: true } allows the data to properly display but when calling model.save() on the model with the hasMany() relationships, all the hasMany associated models stop displaying. This may have something to do with this code Yehuda Katz wrote but I’m not quite sure I understand if this is an intentional aspect of the functionality.

https://github.com/emberjs/data/commit/ce0045758fef559d5f01068c33e19ee4bdbbb6f7

3

I am encountering the same issue and would really like to be able to load all relations before a route is loaded. Currently there doesn’t seem to be an easy way to do this.

4

I have been doing some digging and it seems that there is a possibility that Ember-Data Beta-3 will fix this issue. I tried a work around involving the use of a .then after each save followed by a transitionTo to refresh the route (while using Rest Adapter) and after inspecting the response in the chrome console-network it’s evident that the relationship between the parent model and the hasMany is broken by .save() since every other relationship and property are returned without any issue.

This behavior is listed as a bug on the Ember-Data Git Hub, hopefully it is fixed soon.

https://github.com/emberjs/data/issues/1228 https://github.com/emberjs/data/issues/1177

Similar Problem From another User: Ember Data 1.0 Beta - Relations lost because record is not de-serialized after save? - #3 by mcmanus

5

@LelouchV I figured out how to fix this problem. You can load all associations in the afterModel hook like so:

afterModel: function(model) {
    var store = this.get('store'),
        modelId = model.get('id');

    var promises = [
      store.find('comment', {model_id: modelId }),
      store.find('association', {model_id: modelId })
    ]

    return Ember.RSVP.all(promises);
  }

This solves the problem with loading hasMany’s w/o the async option enabled. However, it appears the save issue still exists with hasMany’s, so hopefully we can find a fix for that soon.

6

So the after model hook is called not only on initial route set up when the route object’s model hook is called but anytime the model is updated? Nice! I will try implementing this and let you know if it works for me as well. Thank you :slight_smile:

7

@LelouchV I don’t think it updates each time the model updates, only the first time, so we have to figure out how to add associations on model update.

8

Turns out the issue is fixed by this PR: https://github.com/emberjs/data/commit/be954be9247fba5ba34783940e7944d76e22e61e

9

I already tried including that PR in my ember-data it hasn’t fixed the issue for me. I think that one specifically is designed to fix belongsTo not hasMany.

10

I added that code to my program as a fix before migrating to the canary build of ED and it fixed hasMany for me. Have you still had issues?