Beta.17 and Beta.18 contained many bugfixes from the community! Please check
them out in the CHANGELOG. Thank you to everyone who submitted
patches!
While many bugs were stomped, some important changes are worth calling out:
(Possibly) Breaking Deprecations
record.constructor.typeKey is now record.constructor.modelName
In Ember Data, when you ask for a model, Ember Data looks its class up using
Ember's Dependency Injection API. When the model class is looked
up, Ember Data stores the type on the model class.
For example, when the following code runs in your application:
var post = this.store.getById('post', 1);

and Ember Data will store the string "post" on the model class:
console.log(post.constructor.typeKey); // 'post'

Ember Data uses this typeKey property internally when creating and extracting
payloads in Serializers, and when locating models in Adapters. The typeKey is
also currently available on Snapshots, which are passed to adapter and
serializer methods. typeKey was previously always normalized to be a
camelCased string.
In Ember Data 1.0.0-beta.18, this property is now called modelName. In
addition, the modelName is a dasherized string. For example, if you had a
model called TacoShop, it would be stored on the model's constructor's
modelName property as taco-shop, whereas previously it would be stored as
tacoShop.
Accessing the typeKey property should still work, but will trigger
deprecation warnings.
If you don't have any custom serializers or adapters, you are good to go;
outgoing payloads and URLs shouldn't change. If you've overridden a method in
your subclass, remember to call this._super, or to normalize modelName in
your code. If you need to transform this string, you can use Ember.String's
camelize and underscore functions. Keep in mind you
can't change modelName on the model's constructor; it is read-only and
will trigger an assertion error if you try to override it.
We changed typeKey to modelName to allow us to align to dasherized strings
as Ember and Ember CLI also align with dasherized strings. Changing the name
allows us to make this change with a deprecation phase.
DS.RESTSerializer.typeForRoot is now DS.RESTSerializer.modelNameFromPayloadKey
To gain more consistency in the naming change of typeKey to modelName,
typeForRoot has been renamed to modelNameFromPayloadKey. The function
serves the same purpose, so this should be a quick refactor you can achieve via
search and replace in your project. While calling typeForRoot will trigger a
deprecation warning, overriding in a subclass won't.
New Features
DS.RESTSerializer.payloadKeyFromModelName
While modelNameFromPayloadKey returns a model for a JSON payload key,
payloadKeyFromModelName can be used to override the serialization of a model
to the server. For instance, you may have a Post model, but your server
expects a message as the root. You can override it like so:
// app/serializers/application.js
export default DS.RESTSerializer.extend({
payloadKeyFromModelName: (modelName) {
if (modelName === 'post') {
return 'message';
}
return this._super(modelName);
}
});

This would produce the following payload:
{
"message": {
"id": "1",
"title": "Action Cable comes with 3 Months of Free HBO"
}
}

Another example is that ActiveModelSerializer uses this hook to convert a
dasherized modelName to an under_scored string.
While this was possible previously in Ember Data, we noticed that users used
several different hooks to achieve this goal, so it made sense to make one
unifying place for this kind of serialization.
store.unloadAll() can now unload all models when not passed a modelName
Previously, store.unloadAll required a modelName argument to unload records
of a type. Now, you can unload all records without calling store.destroy.
Thanks to svox1 for this pull
request!
DS.RESTAdapter.buildURL refactored into different hooks
buildURL has been refactored into several hooks like urlForFindQuery. This
makes overriding methods like buildURL easier to reason about and easier to
change without breaking other request types. Thanks to
thejameskyle for taking on this
refactor!
While beta.17 did introduce a regression, this has been fixed in beta.18.