Polymorphic relationships with unknown model types

[Turbo87]

This issue follows the discussion with @pangratz on Slack regarding the use of a polymorphic belongsTo relationship with model types that might not be known to the app.

My use case is roughly like this:

// models/object.js
export default DS.Model.extend({
  description: DS.attr('string'),
  related: DS.belongsTo('base-object', { polymorphic: true })
});

// models/base-object.js
export default DS.Model.extend({
  description: DS.attr('string')
});

// models/sensor.js
export default BaseObject.extend({
  values: DS.attr()
});

// models/fax.js
export default BaseObject.extend({
  pages: DS.attr('number')
});

From the API I'm getting multiple object objects, each with a type property describing the type of object. Unfortunately the list of types is not fixed and new types can be added by the API authors at any time. Currently a new type will cause an "Unknown model" exception though.

One possible solution to this is checking for the existence of the related model factory in the object serializer and setting related to null if the model can't be found. The only ways to check if a model factory exists right now are a try-catch around modelFor() or manually checking the container for model:.... It might be a good idea to expose some public method for this use case instead.

Another use case of this is running peekRecord() with a type parameter coming from a WebSocket event. In this case I have to handle a missing record via if but then also handle the missing model type by wrapping it in a try-catch.

/cc @pangratz

[pangratz]

Thanks for opening this issue @Turbo87!

[James1x0]

@pangratz I just want to add my 2c since this has bitten me before. Particularly in the area where I may want to have any number of "targets" or "actors" for an app's feed model.

Mongoose uses type keys and they work surprisingly well. I feel the declaration is fairly dry too.
http://mongoosejs.com/docs/populate.html#dynamic-ref

[runspired]

I suspect we can resolve this by eliminating the assertion in modelFor. That assertion seems to be at the wrong level of the abstraction. If, for instance, store.push expects to find a model and doesn't, that should assert. Or if a serializer expects to find one and doesn't, that should assert. But we shouldn't assert modelFor itself considering folks may want (as you noted) to simply validate whether they do have a model by a given name.