Do not call adapter.deleteRecord for a record that is already saved and deleted.
Remove DS.AttributeChange.
Add an example of sending cookie information in the header and updated confusing reopen example.
Allow belongs to associations to be saved when the associated object is null.
[BUGFIX] Normalize typeKeys to always be camelCase

typeKeys must have a strong formatting convention, since they are used
for comparison in several spots of the code. Prior to this commit:

  * The container's normalized version of the factory name was set to
    the typeKey. This leaked the container concerns about name
    formatting up to Ember-Data, and to the user's interaction with
    API calls like `find('some-module')`
  * The typeKey property of a model class was allowed to pass into the
    code without normalization.

In general, for a developer to know which to pick of `find('some-car')`,
`find('someCar')` or `find('some_cars')` they had to understand which
resolver their container was using. This demonstrates a bad coupling,
and makes documenting Ember-Data exceedingly hard (we should not need to
mention a caveat about picking a resolver).

This commit normalizes typeKeys to always be camelCase, both those
returned by `typeForRoot` (for which the documentation has been
improved) and for those set on factories by `modelFor`.

From here on, `find('someCar')` should be considered the standard format
for multi-word model names.
normalizePayload only gets the payload

normalizePayload has been living a lie. It claims to be passed the model
type when called, but in often does not receive this argument (null is
passed instead). This only serves to confuse the use-case for
normalizePayload, and encourage its use when overriding an extraction
helper is actually the right choice.

This tradeoff, dropping the argument of type in all cases, means
normalizePayload can still be run over data added with pushPayload.
pushPayload knows nothing of which model is being pushed, and thus
cannot provide the type reliably.
Merge pull request #1895 from mixonic/normalizeTypeKeys

[BUGFIX] Normalize typeKeys to always be camelCase
Merge pull request #1936 from mixonic/only-payload-to-normalizePayload

normalizePayload only gets the payload
Remove accidentally added capitalize and camelize
Remove unnessary loop in extracting single using DS.EmbeddedRecordsMixin

- updatePayloadWithEmbeddedBelongsTo: removed unnessary loop
Merge pull request #1962 from pixelhandler/updatePayloadWithEmbeddedBelongsTo

Remove unnessary loop in extracting single using DS.EmbeddedRecordsMixin
JSONSerializer should use the attrs hash when extracting records
Also breaks the _super chain in normalize to preserve ordering in the RESTSerializer
Merge pull request #1650 from bmac/json-serializer-attrs

JSONSerializer should use the attrs hash when extracting records
moved normalizeId to JSONSerializer
Merge pull request #1964 from bmac/normalizeId

moved normalizeId to JSONSerializer
Merge pull request #1827 from bmac/more-header-docs

Add an example of sending cookie information in the header and updated...
Add a doc heading for the ActiveModelSerializer class to so its page shows up in the API docs
Merge pull request #1965 from bmac/active-model-serializer-doc

Add a doc heading for the ActiveModelSerializer class to so its page sho...
Copy metadata when it is assigned to recordArrays

Currently metadata is saved on Model classes, such that there is
only ever 1 instance of the meta object in existence. Often however
metadata is a property of a particular array of records and not the
record type. A good example is pagination. It should be possible to
do `store.findQuery()` twice and get two arrays where each has it's
own meta information. However, because metadata is stored on the
Model class, any subsequent request will modify the original
pagination metadata. This commit enables each recordArray to have
it's own unchanging Meta object.
DS.EmbeddedRecordsMixin methods for serializing relationships call super if needed

[Fixes #1971]