#29632: After migrating a Django project from Python 2 to 3, db migration of
django.contrib.sites fails with "TypeError: attribute name must be string,
not 'bytes'"
-------------------------------------+-------------------------------------
Reporter: Florian Mayer | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: needsinfo
Keywords: migration, unicode, | Triage Stage:
bytestring, TypeError | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Mayer):
Tim, I agree that it is absolutely not BaseManager's responsibility to
catch stray bytestrings. My rationale was that, especially with Django
dropping support for Python 2, many others will also be forced to upgrade
their Py 2.x/Django 1.x projects - at the latest when Django drops support
for their 1.x versions. They all would benefit from at least a well worded
warning pointing them into the right direction. However, let me first find
the root cause so I can suggest a meaningful warning / hint.
Interim finding:
After patching BaseManager to print its arguments:
{{{
def contribute_to_class(self, model, name):
if not self.name:
self.name = name
self.model = model
print('django.db.models.manager.BaseManager: {0}, {1},
{2}'.format(self, model, name)) # inserted print debug
setattr(model, name, ManagerDescriptor(self))
}}}
I fount that `./manage.py migrate` gets a spurious `b'objects'` as manager
name from `__fake__.Site`:
{{{
django.db.models.manager.BaseManager: sites.Site.b'objects', <class
'__fake__.Site'>, b'objects'
}}}
Whereas `./manage.py runserver` gets an expected unicode `'objects'` from
`'django.contrib.sites.models.Site`.
{{{
django.db.models.manager.BaseManager: sites.Site.objects, <class
'django.contrib.sites.models.Site'>, objects
}}}
This means that the actual migrations of django.contrib.sites are not
broken, but the unexpected behaviour comes in (at least on my end) through
the `__fake__` class.
While I'm reading up on the gritty details of how Django migrations work
and the inner makings of this `__fake__ ` class, any pointers would be
greatly appreciated.
--
Ticket URL: <https://code.djangoproject.com/ticket/29632#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.939cad5d6409a3f2b393eb1827e3048d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
