-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
using serializer as field fails at import time (e.g. with unit tests) with django 1.7 #1907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I have this same issue but it's happening when I'm starting my wsgi server instead. |
@Geekfish Is your case also tracing back to the translation infrastructure, or are you seeing something that's related to |
edit: didn't realize I clarified that I was using |
@tomchristie
Actually I should clarify, the error doesn't happen on startup, it happens when receiving a request. |
Are there any ideas on how to proceed with this one? I think I understand why this is happening, but I'm not sure of what's the best way to fix. |
The initial fix could cause problems in Django 1.7 when serializers get used as a field. This is due to `force_text` being applied before full initialization of the apps registry (see encode#1907). The fix doesn't seem to be required after version 1.6: https://code.djangoproject.com/ticket/9321
Thanks for taking on this issue, I appreciate it :) |
The initial fix could cause problems in Django 1.7 when serializers get used as a field. This is due to `force_text` being applied before full initialization of the apps registry (see encode#1907). The fix doesn't seem to be required after version 1.6: https://code.djangoproject.com/ticket/9321
The initial fix could cause problems in Django 1.7 when serializers get used as a field. This is due to `force_text` being applied before full initialization of the apps registry (see encode#1907). The fix doesn't seem to be required after version 1.6: https://code.djangoproject.com/ticket/9321
@Geekfish Does the linked commit fix this for you? I'm curious because (although I think it's a good change nonetheless) it doesn't fix the underlying issue for me - I think this goes deeper. When I comment out the call to
Rather than hitting the problem when it tries to load translations, it just hits a bit later when it tries to load all related objects for a model. (This is with a Basically the issue is that a |
(Note: you can work around this by just being careful about where you import your serializers module; you end up doing a lot of imports-within-functions instead of imports at module level.) |
:-| |
@carljm I've since run into this in a second project, and importing inside functions is my current work-around. The cost comes with more friction in adding particular types of tests, but at least I haven't personally seen this new project blow up on requests despite using a serializer as a field (using 2.4.3). |
In general it doesn't cause a problem on actual requests, as long as you don't import your serializers from a |
I'm using DRF 2.4.2 and due to some custom methods / representations, I'm writing some unit tests for my serializers using
py.test
andpytest-django
, which all worked very well.I wanted to change a related field (just showed the ID) to the serialized representation so I used an existing serializer as a field. (as explained in the docs
Running tests using py.test (with pytest-django) will blow up with the giant (sanitized) stack trace shown at the bottom of this post.
Consider the documentation example:
and this key part of the stack trace:
The short version based on my investigation:
TrackSerializer
will happen when this is importedTrackSerializer
is instantiated, it creates all the fields from the model and sets up help text for them (I assume for the html form).runserver
, which I assume is because something to do with the import timing of loading a WSGI app.Where I'm at:
The text was updated successfully, but these errors were encountered: