0

I have an emberjs/ember-data/firebase/emberfire client-side app that Im building. Ember : 1.11.0-beta.1+canary.d2d1490d Ember Data : 1.0.0-beta.14.1 EmberFire : 1.3.2 jQuery : 1.11.2

I have a bidirectional relationship declared in ember-data models

widget model belongsTo customer

customer hasMany widgets

Creating the related widget works fine from the customer controller using addObject()

  // add widget
  var widget = this.store.createRecord('widget', {
    name: data.name.trim(),
    _time: new Date().getTime(),
    customer: model,
  });

  // save and add to model
  widget.save().then(function(widget){
    model.get('widgets').addObject(widget);
    model.save();
  });

An audit of the data in FB and in UI look good.

So, now to actually delete the widget from its widget view controller, (not unlink it from the customer), I want to also cascade the delete to the customer that owns this widget. I'm understanding that this should be automatic with with the correct hasMany/belongsTo setup in the model, but its failing. I think the issue is emberfire, but before I bug report, can someone check me?

if I use destroyRecord() in the WidgetsViewController, the widget is removed, but no cascade to the customer .. also no errors.

Some research suggested using

model.deleteRecord();
this.store.dematerializeRecord(model);

... and maybe because this doesn't persist the delete, no errors. But when you add model.save() to commit the delete, Firebase error:

FIREBASE WARNING: Exception was thrown by user callback. TypeError: Cannot read property 'get' of null
at DS.FirebaseAdapter.DS.Adapter.extend._handleChildValue (http://0.0.0.0:4200/assets/vendor.js:80787:20)

That code shows:

_handleChildValue: function(store, type, serializer, snapshot) {
  //No idea why we need this, we are alredy turning off the callback by
  //calling ref.off in recordWillUnload. Something is fishy here
  if (store.isDestroying) {
    return;
  }
  var value = snapshot.val();
  if (value === null) {
    var id = this._getKey(snapshot);
    var record = store.getById(type, id);
    //TODO refactor using ED
    if (!record.get('isDeleted')) {
      record.deleteRecord();
    }
  } else {
      ...
  }
}

So can anyone shed light on whether there is a reason firebase developer thought this wasn't needed or whether it is and its just not implemented? .. or perhaps point me in another direction that does work?

---------- update added model relationships ---------------

// customer model
import DS from 'ember-data';
export default DS.Model.extend({
  name:  DS.attr('string', { async:true }),
  widgets: DS.hasMany('widget', { async:true }),
  _time: DS.attr('number', { async:true }),
});

// widget model
import DS from 'ember-data';
export default DS.Model.extend({
  name: DS.attr('string', { async:true }),
  _time: DS.attr('number', { async:true }),
  customer: DS.belongsTo('customer', { async:true })
});
Community
  • 1
  • 1
Tremendus Apps
  • 1,497
  • 12
  • 20
  • `model.get('widgets').addObject(widget);` - you should remove this. If widget has correct `belongsTo`, it will be automatically added to widgets - if not, then please post models code here. – Daniel Kmak Jan 26 '15 at 23:28
  • Yeah, sure enough. I figured you'd have to save the creation of the association, and the videos and code examples I saw did it this way too. Still doesn't help my removal issue though? Have you experience in deleting a related record from the related records primary controller (rather than from the associated models controller?) – Tremendus Apps Jan 26 '15 at 23:40
  • Remove whole line. As long as you use relationships it should already be there. – Daniel Kmak Jan 26 '15 at 23:41
  • It looks like [this problem and a workraound](https://github.com/firebase/emberfire/issues/143) have already been discussed in the project's issue tracker [more than once](https://github.com/firebase/emberfire/issues/165); seems like that should be a first stop for any OSS project. – Kato Jan 27 '15 at 21:04

0 Answers0