'type' fieldname isn't allowed on models

[e3b0c442]

Hi all,

This started popping up after upgrading to EDA 1.1.0:

TypeError: str.replace is not a function
    at Object.func (ember.debug.js:35225)
    at Object.Cache.get (ember.debug.js:12867)
    at decamelize (ember.debug.js:35267)
    at Object.func (ember.debug.js:35182)
    at Object.Cache.get (ember.debug.js:12867)
    at Object.dasherize (ember.debug.js:35271)
    at ember$data$lib$system$normalize$model$name$$normalizeModelName (normalize-model-name.js:13)
    at ember$data$lib$serializers$json$serializer$$default.extend.modelNameFromPayloadKey (rest-serializer.js:426)
    at ember$data$lib$serializers$json$serializer$$default.extend._normalizePolymorphicRecord (rest-serializer.js:161)
    at ember$data$lib$serializers$json$serializer$$default.extend._normalizeResponse (rest-serializer.js:248)onerrorDefault @ ember.debug.js:29632exports.default.trigger @ ember.debug.js:50945(anonymous function) @ ember.debug.js:51937Queue.invoke @ ember.debug.js:978Queue.flush @ ember.debug.js:1042DeferredActionQueues.flush @ ember.debug.js:838Backburner.end @ ember.debug.js:166Backburner.run @ ember.debug.js:288run @ ember.debug.js:19102ember$data$lib$system$adapter$$default.extend.ajax.Ember.RSVP.Promise.hash.success @ rest-adapter.js:738jQuery.Callbacks.fire @ jquery.js:3099jQuery.Callbacks.self.fireWith @ jquery.js:3211done @ jquery.js:8264jQuery.ajaxTransport.options.send.callback @ jquery.js:8605

This seems to only be happening on an asynchronous load. The model in question is called 'ticket-type'. No issues with EDA 1.0.0; I upgraded to EDA 1.1.0 to facilitate the upgrade to Ember 2.0/ED 2.0.1, however I rolled back the Ember updates to the latest 1.13.x releases for both Ember and Ember Data and still get the error. Rolling back to EDA 1.0.0 clears the error.

[benkonrath]

Thanks for the bug report. Does this only happen with the 'ticket-type' model or with other models as well? Would it be possible for you to create a failing test case for this?

[e3b0c442]

Bear with me here, I'm trying to figure out the best way to get this in a test case.

I discovered with further debugging that the name of the relationship seems to be irrelevant. The value for the relationship (ticket -> ticket-type) is what ends up in "str"... the value is a number which corresponds to the primary key for the type. Oddly, this is not the only time primary keys are represented as raw numbers in the API, so the unique part about this continues to be that the data is deeply nested. It almost seems as though a coerce-to-string function is being skipped somewhere based on the condition.

[e3b0c442]

Well, on a whim I made a change and it appears to have resolved the issue.

The relationship between 'ticket' and 'ticket-type' was called 'type.' I changed 'type' to 'system' on the API and frontend thinking there might be a conflict, and lo and behold the issue is gone.

I think the root of this may have been in RESTSerializer. If you guys want to investigate further please feel free, but this workaround will work for me.

[benkonrath]

Thanks for finding the issue. It looks like 'type' is a reserved field in the RESTSerializer so we should probably document this.
https://github.com/emberjs/data/blob/v2.0.0/packages/ember-data/lib/serializers/rest-serializer.js#L165

Here's the ember-data issue where this functionality came in.
emberjs/data#3547

It might be better to fix this in our adapter (or in ember-data itself) by supporting the 'type' field as a polymorphic model only if the value is a model. Otherwise, it would be a regular field. My guess is that 'type' is reserved in rails somehow which is why it's natural for this to be included in the RESTSerializer.

I'm re-opening this so that we can properly deal with it. Thanks again for digging into the problem.

[benkonrath]

This bug might be causing the problem.
emberjs/data#3725
I need to investigate a bit but I won't have time until next week.

[benkonrath]

I investigated a bit and I'm pretty sure that this is the ember-data issue that's referenced above. This problem fixed in Ember Data v1.13.12. I don't think it's worth writing a test in EDA because it's an ember-data issue.