Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

model.save() resolves lazy-loaded attribute before PUT #1312

abobwhite opened this Issue Sep 16, 2013 · 2 comments


None yet
2 participants

Using Ember Data Canary Build from 9/16/13

I have a model that lazy-loads its products so I don't have to GET them when I don't need them:

App.Supplier = DS.Model.extend({
  products: DS.hasMany('product', {async : true}),

On a particular template, a Supplier can edit their profile (which does not need their "products"). After modifying attributes, I call supplier.save() to persist those changes. Normally (without the lazy-loaded attribute), this works fine. However, with adding in products: DS.hasMany('product', {async : true}),, when supplier.save() is called, there is first a GET for the products which is specified in the links hash. The GET resolves and the PUT resolves, however, due to my cookie security, every call to the server changes the cookie to prevent cookie theft. Since this GET is made out-of-band, it causes issues with the actual PUT thinking the cookie has been stolen since the GET doesn't return before the PUT takes place.

The main issue I have: Why does supplier.save() trigger a GET for the lazy-loaded products? I don't need them, I don't want them - why is ember data trying to get them for me?

Thanks to @wycats , I was able to use this workaround:

App.ApplicationSerializer = DS.RESTSerializer.extend({
  serializeHasMany: function(record, json, relationship) {
    if (relationship.options.async) { return; }

    return this._super.apply(this, arguments);

wycats commented Sep 18, 2013

The correct semantics here probably depend on whether the async relationship is loaded, and whether it is strictly needed in order to save. I'm going to continue to leave this up to customizations in the adapter for a while and see what common semantics we can extract.

@wycats wycats closed this Sep 18, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment