Get rid of warning

#27 · closed · 3 comments

View on GitHub ↗

dbrgn

I have a use case where I need to dynamically determine the nested serializer like this: ```python def get_config(self, tracker: Tracker): config = tracker.get_config() if config is not None: serializer = TRACKER_CONFIG_SERIALIZERS.get(tracker.model) if serializer is None: logger.warning('Could not find serializer for model %s', tracker.model) return None return serializer(config).data return None ``` This works but results in a warning, because the nested serializer does not have access to the request in the context. If we pass in the context... ```python return serializer(config, context=self.context).data ``` ...then the warning is gone, but the filtering is applied to those fields too. The problem is that drf-dynamic-fields cannot know that this serializer is a nested serializer because it's used like a root serializer. And I'm afraid of playing some tricks with parent/child attributes, since that can go wrong easily. I see two approaches to solve this: - Remove the warning (no filtering if there's no request in the context) - Add a special field to the context (e.g. `dynamic_fields_ignore`) that is queried in order to ignore the filtering on this serializer. I'm undecided. What do you think @jtrain?

Comments

jtrain

i don't have any special love for the warning. Removing it would be a positive thing for my code. As for optionally warning or not, there might be a few ways to go about it. 1. As you said we could have some special field set on the serializer somewhere; or 2 it could be a settings.py setting; or 3. We keep the warning, but document how you'd turn it off with the python logging framework, though that would mean turning all warnings for the lib off, not just this one; or 4. we demote the warning to a log level or debug level warning so people could switch them off

jtrain

Finally another option completely (to work around this with existing code) is to provide a clean serializer in your codebase without the dynamic field mixin, and a second serializer which simply inherits the first with the mixin. e.g. `SchoolSerializer`; and `DynamicSchoolSerializer`

dbrgn

> As you said we could have some special field set on the serializer somewhere; or 2 it could be a settings.py setting I like that. Implemented in #28.