How it works...

As you can see, this snippet is more complex than the previous ones. The object_relation_mixin_factory, which we have aliased to generic_relation, for short, in our import, is not a mixin itself; it is a function that generates a model mixin – that is, an abstract model class to extend from. The dynamically created mixin adds the content_type and object_id fields, and the content_object generic foreign key that points to the related instance.

Why can't we just define a simple model mixin with these three attributes? A dynamically generated abstract class allows us to have prefixes for each field name; therefore, we can have more than one generic relation in the same model. For example, the Like model, which was shown previously, will have the content_type, object_id, and content_object fields for the favorite object, and owner_content_type, owner_object_id, and owner_content_object for the one (user or institution) that liked the object.

The object_relation_mixin_factory function, which we have aliased to generic_relation, for short, adds the possibility to limit the content type choices by the limit_content_type_choices_to parameter. The preceding example limits the choices for owner_content_type to only the content types of the User and Institution models. Also, there is the limit_object_choices_to parameter, which can be used by custom form validation to limit the generic relations to only specific objects. For example, we might want to allow favorites for only the objects with a published status.