You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JSON responses are deserialized into "wrapper" classes and where no wrapper class is given, a class is chosen by looking for a Ruby class with the same name as the @type of the resource.
However, resources will often be decorated with more than one type, for example if there is a subclass relationship and this is made explicit in the data.
The current approach is to just take the first class that matches the name of the first resource type.
This leads to indeterminacy if we make use of a type hierarchy in the Ruby model classes, as we may pick an arbitrary class if more than one type is given.
Ruby 2.7 still only has rudimentary support for classes, but we should be able to discount any wrapper classes that are the supertype of any other wrapper class found for the given list of types of the resource.
The text was updated successfully, but these errors were encountered:
JSON responses are deserialized into "wrapper" classes and where no wrapper class is given, a class is chosen by looking for a Ruby class with the same name as the
@type
of the resource.However, resources will often be decorated with more than one type, for example if there is a subclass relationship and this is made explicit in the data.
The current approach is to just take the first class that matches the name of the first resource type.
This leads to indeterminacy if we make use of a type hierarchy in the Ruby model classes, as we may pick an arbitrary class if more than one type is given.
Ruby 2.7 still only has rudimentary support for classes, but we should be able to discount any wrapper classes that are the supertype of any other wrapper class found for the given list of types of the resource.
The text was updated successfully, but these errors were encountered: