If you rebase (to get 49a66fe) this should pass in CI...

@runspired - Wanted to get your thoughts here too...

I thought Stef had recently fixed this, hrm

This is fixed, if you load models via the container and a modern resolver. The above should only benefit tests. And if so, should likely be a test specific reopen.

@stefanpenner, can you elaborate?

This code:

  model() {
    return RSVP.hash({
      nodes: this.get('store').findAll('node'),
      agents: this.get('store').findAll('agent'),
    }).then(({ nodes }) => {
      console.log(nodes.get('firstObject').toString());
      console.log(nodes.get('firstObject').constructor.toString());
    });
  },

Yields this output:

<nomad-ui@model:node::ember844:69b5c85f-5356-4365-b75a-e37ca76adfc3>
(subclass of DS.Model)

With these dependencies:

DEBUG: Ember           : 2.14.1
DEBUG: Ember Data      : 2.14.4

Was this fixed after 2.14.4, or is there another explanation?

<nomad-ui@model:node::ember844:69b5c85f-5356-4365-b75a-e37ca76adfc3>
(subclass of DS.Model)

ah..

This seems reasonable, unless we want to remove modelName from classes, as that attribute does pollute the class...

I'll have to think about this some more.

IMHO, deprecating modelName is a separate concern, we should just make sure that we don't box ourselves in a corner with it. IMHO, the same thing could be solved without modelName via _debugContainerKey (for example)...

IMHO, the same thing could be solved without modelName via _debugContainerKey (for example)...

On the class, I don't believe we put _debugContainerKey on the class?

I don't believe it is possible for us to move off of modelName being on DS.Model without moving to ES Classes. Moving to ES Classes is on the roadmap anyway, and would mean that the class name would be available (and the default) for this situation. Due to this, I personally do not see any issue with moving this PR forward with the use of modelName.

@rwjblue @stefanpenner what do you think?

Moving away from modelName just means we need some other mechanism for the same rough thing, whenever we add that we can easily update this toString implementation...