Mirage fails with 'model.hasInverseFor is not a function'

[markpatton]

I have a github repo which is setup to demonstrate the issue here: https://github.com/markpatton/mirage-test
Mirage version 0.40.0
Ember version 2.16

There are two models, grant and user. The grant creator attribute is meant to be a user object. There are fixtures to load test grant and user objects.

I am using mirage to mock get and post to /api/grants.
If you run "ember test" you will get the failure: model.hasInverseFor is not a function
(You can also visit /grants in the application to see the failure.)

The issue seems to be the belongsTo relationship of the creator attribute of the grant model to the user model. If I change the creator attribute to a string, there is no failure. In the grants fixture, if I remove the creator attribute from the first object, again there is no failure.

[markpatton]

If I change the belongsTo relationship in the grants model to hasMany, then things work.

[aaronfischer]

@markpatton Obviously changing your belongsTo to hasMany isn't ideal, did you stumble upon any other resolutions? (I'm encountering this issue as well after upgrading from 0.3.2 to 0.4.1)

[markpatton]

@aaronfischer I finally decided to avoid mirage fixtures and just load my test data in the application route. It was not ideal, but worked well enough for the demo I was building.

[aaronfischer]

@markpatton So it all stemmed from using fixture data that contained relationships? If you created the fixture records "manually" in a scenario would this have solved your issue?

[markpatton]

@aaronfischer It may be specific to fixtures. In my particular case, using the store to create records was simpler than setting up factories and using a scenario.

[mnoble01]

UPDATE

This error stemmed from my misunderstanding of the difference between the Schema and the DB. Turns out I was passing db model objects as a relation rather than schema models.

Since there is error handling when passing a schema model instance to another on create/update without an explicit association, perhaps error handling for the opposite case would be helpful as well. That is, passing a non schema model to a model create/update call when an association exists.

Sorry for the noise on this ticket!

---

This is reproducible without fixtures.

One of my ember-data models has a fragment array. I added a mirage model to represent a single fragment and added a belongsTo({polymorphic: true}) relationship.

// fragment-model
import { Model, belongsTo } from 'ember-cli-mirage';

export default Model.extend({
  parent: belongsTo({ polymorphic: true }),
  otherModel: belongsTo(),
});

// parent model
import { Model, belongsTo } from 'ember-cli-mirage';

export default Model.extend({
  fragments: hasMany('fragment-model'),
});

The described error was thrown when attempting to create a fragment-model instance.

// model factory
import { Factory } from 'ember-cli-mirage';

export default Factory.extend({
  afterCreate(model, server) {
    server.create('fragment-model', {
      parent: model,
      // This line causes the error:
      // It should be server.schema.find instead of server.db.find
      otherModel: server.db.find('other-model', otherModelId), 
    });
  },
});

[samselikoff]

Sorry for the massive delay on responding to this.

The problem was in your fixture file:

export default [
  {
      id: 1,
      number: '0xDEADBEAF',
      agency: 'NIH',
      creator: 1
  },

Mirage's ORM expects foreign key names to be *Id or *Ids. So in your case, changing the key to creatorId: 1 fixes the bug. (creator would expect an instance of a User model.)

I agree with @mnoble01 we should add some assertions here to warn users.

[samselikoff]

Assertions added in #1356