Improve store implementation

[ckung]

Since the container lives on Ember.Store, we should be creating and maintaing records via the store. This means most of the model functionality will be moved to the store module. Two side effects of this refactor are -

1. Consolidate record creation logic
2. Stop setting the adapter instance on the class

[kennethkalmer]

Carrying on from #354 (and originally stefanpenner/ember-cli#594)... The container looks great, and it definitely looks like a solution for resolving circular dependencies with ES6 modules at runtime.

I'm just thinking out loud here. I've got a function I use to prefetch a bunch of different models with one API call, and then use Ember.Model.load() to seed the caches on each model. This worked really well, until I ran into the issue I reported on ember-cli.

Reading the other two issues will fill in the missing context

Now I'm testing a scenario where I simply pass the store down from a controller into my prefetcher, so it can be used by the prefetcher to load data onto another model, for example:

var User = Ember.Model.extend({
  someCollection: []
});

var prefetcher = function( store, user ) {
  // fetch data omitted
  promise.then(function(data) {
    SomeModel.load( data.some_model );
  });

  // more processing omitted
  promise.then(function() {
    var fp = SomeModel.find([ 1, 2 ]);
    fp.then(function(collection) {
      user.get('someCollection').replace(collection);
    });
  });
}

var SomeController = Ember.Controller.extend({
  init: function() {
    var user = this.get('store').createRecord('user');
    prefetch( user, this.get('store') );
  }
});

It seems the RESTAdapter has lost the findMany function, so this isn't working anymore.

Apologies for the vague example code. The reality is that there is a big graph of relationships going on, all populated by the prefetcher. Then, the someCollection property on the User model just shortcuts the graph by giving easy access to data a few steps away, and in a way that makes sense in the application domain.

[kennethkalmer]

Seems I've been smoking my socks, there has never been a RESTAdapter.findMany, which makes sense. Let me add my own and see how this goes. Noting this because the documentation should probably reflect it.

[kennethkalmer]

Should Model.findMany and Model.fetchMany not be using the sideloaded data to avoid requests to the server that could be fulfilled from the cache?

I'll gladly take a stab at this, cause this the behavior I'm depending on. Otherwise using Model.load is moot in my example above and I would have to figure out an alternative strategy. I thought about iterating over the responses and using Model.create to force the instances to be properly created in the cache and not just stashed away in the sideloaded hash, but then I remembered that later calls to find, even if done separately, will coalesce into a single findMany call...

Running out of ideas, would a PR be accepted for this behavior ?

[ahacking]

Can you explain how you are supposed to use the store and specifically how to specify the adapter for a model?