Singleton Record Data
RecordData can be implemented as a singleton, eliminates several redundant APIs
that creeped into the original implementation, and simplifies the method signatures of
RecordData APIs by using
RecordData is the data-cache primitive for information given to
ember-data, and while
a cache-per-entity setup is sometimes desired, a singleton cache offers opportunities for
performance optimization and improved feature sets. Current default
InternalModel which it replaced are examples of cache-per-entity strategies.
Our original intent when discussing
was for it to be possible to be implemented as a singleton; however, this intent was not
captured well in that RFC and while the APIs presented there would have enabled it, the
actual implementation differed in ways that prevent
The introduction of
Identifiers presents us with a good opportunity to refactor the API
surface of our cache-primitive, simplifying and streamlining how it works while solidifying
and codifying its ability to be a
Previously, to deal with the lack of a unified identifier concept, we overloaded many
RecordData method signatures with
modelName, id, clientId as
arguments. The original intent was to overload all of their method signatures
in this way to ensure
singleton implementations could be built, but we failed to
correctly implement the original
RecordData RFC in this regard.
The introduction of
Identifiers provides us a cleaner interface for communicating identity
in these APIs. For uniformity, methods will always take an
identifier as their first
RecordData is a public userland interface we
must rely on capabilities reporting to handle the
deprecations for it introduced by this RFC.
We will use this opportunity to improve the encapsulation
RecordData via introduction of a sandbox.
This sandbox will be responsible for handling interop,
deprecations and other book-keeping tasks we require as needed
while ensuring that
RecordData implementations are properly
encapsulated (e.g. implementations can only talk to other
implementations via public API).
RecordData implementations must now specify a
The implicit version when unspecified is
"1" (the version
which this RFC supplants and deprecates). Implementations
without a version or with a version equal to
receive a deprecation notice the first time an instance of
a previously unseen
RecordData class is encountered.
In keeping with the support policy of
ember-data will support the versions of
current at the time of the last two
The APIs proposed by this RFC constitute version
and will be used by
ember-data when the following is
recordData.version === "2";
It is possible that once this upgrade to
identifiers has occurred that we never need to
version again. If so, a future RFC may choose to deprecate the
property altogether once "version 1" is no longer supported.
The sandbox implementation would guarantee the following
Beginning with this RFC,
StoreWrapper.recordDataFor will no longer directly return the
instance provided by the
createRecordDataFor hook, instead returning a delegate.
This encapsulates the
RecordData feature ensuring that communication is via public API
and provides us the ability to manage the three concerns listed above and described below.
RecordData method or method signature is deprecated, we will detect calls to deprecated
methods or calls using deprecated method signatures and print the appropriate deprecation messages.
RecordData method or method signature is deprecated the instance provided by
may not have implemented the deprecated method or signature. Using the supplied version, calling context,
and other information available we will transform calls to deprecated methods or signatures
into their supported equivalent.
Updates to Store Methods
Updates to StoreWrapper Methods
Updates to RecordData Methods
How we teach this
RecordData is primarily an API meant for power-user addon-authors,
and not something we expect everyday users of
ember-data to be intimately
familiar with. It is unlikely that we produce a
guide for using
typescript interface for
RecordData should be introduced with
API Documentation for the available APIs and their roles.
It introduces churn in APIs we only recently introduced (in the past 6 months); however we have strong reason to believe that very few implementations exist and that those which do have their migration path covered by the sandboxed RecordData implementation.
- keep the status quo: large number of arguments to methods, no support for singleton RecordData,
IdentifierRFC largely useless and makes future iteration on RecordData similarly difficult.