Polymorphic Relationships

[molligan]

Does emberfire support polymorphic ED relationships? I have tried searching on the web, and doing a few implementations but I have run into trouble. I just want to make sure that polymorphic relationships are indeed supported.

[tstirrat]

We do not provide any specific support in our adapter. What issues are you running into?

[tstirrat]

I've done some of my own testing and it seems we do not currently support polymorphic relationships.

The records are saved into their own collections, which defeats the purpose of polymorphism, and an error shows when trying to reload the relationships:

Uncaught TypeError: Cannot read property 'typeKey' of undefined

[molligan]

Yes, I ran into this same issue. I was hoping the polymorphic relationships were supported, but as you have pointed out, it looks as though this is not the case.

[sheldonbaker]

I'd love to have this working. I'm a newbie to firebase, but have some experience drilling down into ED serializers. I assume, at a high level, that records simply need to be saved into their own collections with a type attribute?

[molligan]

I agree with you. I'm not terribly experienced in either firebase or ember data, but when I was working with polymorphic relationships in ember data and I would create a child record, the ember inspector would show record creation of both the child and parent with the same firebase ID simultaneously. This was helpful in allowing you to reference the child object from the parent class. Having a similar implementation in emberfire would definitely be helpful.

Sent from my iPhone

On Apr 25, 2015, at 7:58 PM, Sheldon Baker [email protected] wrote:

I'd love to have this working. I'm a newbie to firebase, but have some experience drilling down into ED serializers. I assume, at a high level, that records simply need to be saved into their own collections with a type attribute?

—
Reply to this email directly or view it on GitHub.

[sheldonbaker]

@molligan I think however this feature is implemented, that behaviour in the ember inspector would remain the same.

I dug around in the adapter and serializer and made some hack-ish progress, but I'm not sure how to go about it in the following case:

Owner = DS.Model.extend({
  pets: DS.hasMany('pet', { polymorphic: true, async: true }
});

Dog = Pet.extend();
Cat = Pet.extend();

Breeder = DS.Model.extend({
  dogs: DS.hasMany('dog')
})

In updateRecord, this._getRef(type, record.get('id')) is responsible for passing the correct root key to save in Firebase (i.e., pets or dogs). For polymorphic relationships, type should actually be type.superclass (ignoring multi-level/recursive polymorphism for the moment). However, this isn't always the case. If we do breeder.get('dogs.firstObject').save(), that object should be saved in dogs, but if we do owner.get('pets.firstObject').save(), we'd expect that object to be saved in pets.

I'm sure there's other design decisions as well that need to be made before polymorphism can really be supported.

[wolfbiter]

+1 for polymorphism support

i'm new to firebase but i love the idea of ember-cli firebase :) full stack goodness.

[wolfbiter]

@tstirrat did some investigation, looks like belongsTo polymorphism works with a simple fix... dunno if this helps.

Problem with current firebase is {polymorphic: true} expects data[key + 'Type']
store code:

function typeFor(relationship, key, data) {
  if (relationship.options.polymorphic) {
    return data[key + "Type"];                /// THIS LINE returns "null"
  } else {
    return relationship.type;
  }
}

my "fix":

import Ember from 'ember';
import DS from 'ember-data';

export default DS.FirebaseSerializer.extend({

  // Patch polymorphism until part of Ember Firebase. https://github.com/firebase/emberfire/issues/245
  serializePolymorphicType: function(snapshot, json, relationship) {
    var key = relationship.key,
        belongsTo = snapshot.belongsTo(key);
    key = this.keyForAttribute ? this.keyForAttribute(key, "serialize") : key;

    if (!Ember.isNone(belongsTo)) {
      json[key + "Type"] = belongsTo.typeKey;  // ADD data[key + "Type"]
    }

    console.log("serializePolymorphicType", snapshot, json, relationship);


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

});

[natecox]

+1 for polymorphic relationships. I assumed that this would be included and it's causing me some major issues with my data modeling.

@wolfbiter do you have any suggestions on adding hasMany polymorphism?

[alejandrocarlos]

+1 for polymorphism. Firebase is awesome but I would like to have full support of all EmberData features.

[DarioSoller]

+1. Just could say the same as @alejandrocarlos .

[DougPuchalski]

+1

[leifcr]

I've started looking into this, and it is a bit complicated, but it should be possible.
There are some resources here: https://github.com/Bestra/ember-data-sti-guide about the actual implementation.

I'm unsure if this is fit for being part of the official EmberFire adapter, and if so it needs to be optional, as implementing it will break current sites that might have polymorphic data in multiple tables.

Most implementations do handle this on the server side as well, since allowing the client to push 'any' type into the store, might cause application issues. E.g. if you have the following

Pet = DS.Model.extend({
  name: DS.attr('string'),
  type: DS.attr('string')
});

Dog = Pet.Model.Extend({
 type: 'dog';
})
Cat = Pet.Model.Extend({
 type: 'cat';
})

The client can potentially change the code to push type of 'donkey' into the store, and if so, your application might/will error when loading the data.

Ember Data polymorphic associations assume one endpoint per model, and assumes the polymorphic storage to be handle server-side and not client side.

A recommended talk on the subject: https://vimeo.com/115987599

The simplest solution is to override the pathForType and look for either a type , _type or polymorphic_type key in the push and find functions in EmberFire.

The implementation should briefly be:

• Update all tests to Ember 2.0 and Ember Data 2.0 Update to Ember 2.0 and Ember Data 2.0 and updates tests accordingly #310
• Change the serializer to include type , _type or polymorphic_type when association is polymorphic
• Change pathForType to override the path for polymorphic - [], that are not embedded
• Change the embedded storage key for polymorphic associations
• Change the find methods to set the models properly depending on recieved type
• Fix the push function to use data.type instead of type

I will try to make the changes and do a PR, however it will take time. Please provide comments/thoughts on the subject.

[leifcr]

Any preference if polymorphic STI should be default, opt-in or opt-out through configuration?

[natecox]

I'd say it should be default with the option to opt-out.

[alejandrocarlos]

I'd say opt-out through configuration.

[leifcr]

After a week + a bit of testing, here's a few findings.

Polymorphic STI

Ember Data assumes polymorphic STI records to have separate endpoints. Example:

Shape = DS.Model.extend({}); // endpoint shapes
Circle = Shape.Model.extend({}); // endpoint circles
Rectangle = Shape.Model.extend({}); // endpoint rectangles

It is possible to force loading/storing circles and rectangles through shapes, so it will appear as single table inheritance storage, however, when you do these steps: (Assuming patch for path/type is properly set up)

Create record

c = store.createRecord('circle');
c.save() // saves to /shapes/ (assuming id = 1)

Find record

// Find shape with id 1, will load into circle, since type = 'circle'. Will load from backend/firebase.
store.find('shape', 1) 

Triggering find again

store.find('shape', 1) 
// Will load from backend/firebase again, since ED knows that it does not have a shape with ID 1.

So this breaks caching of objects in the ED store. I still haven't solved how to do this properly in the store.

If anyone has suggestions on how to fix this both for the adapter and for the ED store, please provide feedback.

Polymorphic relationships.

Example:

Taggable = DS.Model.extend({
  tags: DS.hasMany('tag', {async:true})
});

Post = Taggable.Model.extend({
  tags: DS.hasMany('pet', {async: true, polymorphic: true} )
});
Image = Taggable.extend({
  tags: DS.hasMany('pet', {async: true, polymorphic: true} )
});
Tag = DS.Model.extend({
  taggable: DS.belongsTo('taggable', {async:true, polymorphic: true})
});

This seems to work out of the box.

The last combination is STI with polymorphic relations, and that cannot be solved before I've figured out more of the details on fixing STI for firebase.

All examples i've come accross implements botht eh STI endpoint and the model specific endpoints, so ember-data and the adapter does not have to be 'monkey-patched'.

I still think it's fixable on the adapter side, but it takes time to solve properly.

@tstirrat Are there any configuration options on the serverside to e.g. morph/copy data when it's recieved on one endpoint? Or does everything have to be client-side?

[leifcr]

Seems like STI can be problematic. See emberjs/data#2407

[leifcr]

RFC on emberjs/ember-data emberjs/rfcs#67
PR for polymorphic find, which we need to implement STI functionality in firebase emberjs/data#3105

[Iamlowlo]

Hi there!
A newbie on ember/firebase here. I think on polymorphic relationship as the perfect solution to apply on my app, but not the only one.
Is it already working on emberfire or should I use the other option?
thanks!

[tstirrat]

Hi Carlos, we don't support polymorphic relationships in EmberFire at the moment. We're waiting on clearer directions in the underlying Ember Data.

[leifcr]

Ember data 2.6 will have a new ids-and-type strategy which may lays parts of the groundwork needed for this to be possible. See http://emberjs.com/blog/2016/05/03/ember-data-2-5-released.html#toc_upcoming-features-in-ember-data-2-6-beta-1

[tpetrone]

Any update on this? Thank you.

[leifcr]

@tpetrone Have to wait for emberjs/rfcs#67