Add support for DRF-like Meta classes inside custom serializer#72
Open
jacobstoehr wants to merge 8 commits into
Open
Add support for DRF-like Meta classes inside custom serializer#72jacobstoehr wants to merge 8 commits into
Meta classes inside custom serializer#72jacobstoehr wants to merge 8 commits into
Conversation
This was achieved by adding a check if there is a `Meta` class present inside the custom serializer. Now, if that class exists, an attempt is made to get the model information for both Django models as well as SQLAlchemy models. Others are not supported and will raise a RuntimeError. The `_field_map` is then updated accordingly, but MethodFields or custom `attr` keyword arguments are not overwritten.
This makes it possible to not serialize certain fields.
By adding a `fields` parameter which can be either '__all__' or a list of fields from the model. And by making this `fields` attribute or the `exclude` attribute usable, but not both at the same time.
And minor readability improvements.
Before, the `direct_fields` dict holding all fields declared in the custom serializer was overwritten with all implicitly defined fields from the `Meta` class inside the custom serializer. That means if someone declared anything other than a standard Field for an attribute of the model, this would have been overwritten with a standard Field instance instead of keeping the explicitly declared field type, effectively nullifying the effect of the explicit declaration. Now, if someone was to declare a field explicitly, the SerializerMeta class will not overwrite this field with a standard Field instance in the `direct_fields` dict, but will instead skip this field, thus preserving the explicit declaration. Also add some more comments explaining this in the code.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If pulled, this would extend serpy with the ability to accept a
Metaclass inside the custom serializer class.The syntax for this class is heavily borrowed from DRF's ModelSerializer, e.g. it needs a model (either Django or SQLAlchemy) and an
excludeorfieldsattribute which tell serpy which fields to exclude or include in the serialization.This was inspired by the need to serialize a very big Django model but with greater speed than what DRF provides. However, this had the drawback of also needing to specifiy each field to be serialized in the Serializer, instead of just inserting a
Metaclass and be done.I have done some basic benchmarks, this does not negatively impact the standard serialization speed, because of the top level
if meta:statement, which will just skip the code if noMetaclass is provided. If the class has been provided, the serialization speed doesn't suffer, at least on my machine. I have not conducted any kind of statistical benchmarking, just quick tests using the UNIXtimeutility.I wanted to keep this code inside the SerializerMeta, so that the implicit fields are calculated at startup time, not at serialization time. This however means all serializers inheriting from
serpy.Serializerwill have this ability, not like DRF where only serializers inheriting fromrest_framework.serializers.ModelSerializerwill have this ability.