By default, the serialization scope uses current_user, and you can
now reference the scope as "current_user" in the serializer. If you
override the scope using "serialization_scope" in your controller,
it will use that method name instead.
This is to ensure that PORO's as_json is called if no serializer
is specified.
Original behaviour was that serializable_hash was being called,
overriding the as_json method.
This enables the deferral of the resolution of the serializer class to prevent NameError exceptions due to reference cycles between serializer classes.
An `_id` suffix will be appended to the name of HasOne associations, while `_ids` will be appended to the singularized name of HasMany associations. Association keys can still be overridden with the `key` option.
Furthermore, objects embedded in the root are now by default named according to their serializer, instead of the key used for their associations.
We do not know the type for computed attributes, so we pick nil.
Perhaps at some point we might add a :type option for attributes (or
not), but in any case it's important to not crash when there are
computed attributes.
To achieve this, we make the following change when sideloading: Instead
of serializing associations and discarding duplicate *hashes*, we
memorize the *objects* (records) that we have already serialized, and
only serialize those that are new.
This change is mostly transparent, and brings down serialization time
from 3.1 seconds to 1.0 seconds on my set of sample data.
There is one change in the behavior: If you sideload the same object
multiple times, and it yields different hashes, like so:
embed :ids, include: true
has_many :comments
has_many :recent_comments, root: comments, serializer: CommentShortSerializer
then previously, it would be included multiple times, whereas now, the
first hash wins. (I haven't actually tested this.) I don't know that
either option is preferable. It's not covered by the test suite, and I
think it's an edge case that is OK to ignore entirely.
ActiveRecord::Base and ActionController::Base"
The whole idea of having a lazy hook is that it can be executed
in the context of different targets. The moment you hardcode the class,
the hooks can no longer run in the proper context.
This reverts commit 506e2ac9ad.
