Error in reverse m2m query if the model with ManyToManyField has CharField primary key

[prashant.a.borde@…]

Here is my models.py file:

from django.db import models
import uuid

class Group(models.Model):
	Name = models.CharField('Name', max_length=100)

class UserProfile(models.Model):
	id = models.CharField(primary_key=True, max_length=32, default=str(uuid.uuid4()).replace('-', ''))
	Name = models.CharField('Name', max_length=100)
	groups = models.ManyToManyField(Group, null=True, blank=True)

I execute following commands on Django shell (manage.py shell):

>>> g1=Group(Name='g1')
>>> g1.save()
>>> u1=UserProfile(Name='u1')
>>> u1.save()
>>> u1.groups.add(g1)
>>> Groups.objects.filter(userprofile=u1)

The last command (a reverse m2m query) throws following error:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
NameError: name 'Groups' is not defined
>>> Group.objects.filter(userprofile=u1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 155, in filter
    return self.get_query_set().filter(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 655, in filter
    return self._filter_or_exclude(False, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 673, in _filter_or_exclude
    clone.query.add_q(Q(*args, **kwargs))
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1266, in add_q
    can_reuse=used_aliases, force_having=force_having)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1197, in add_filter
    connector)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/where.py", line 71, in add
    value = obj.prepare(lookup_type, value)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/where.py", line 339, in prepare
    return self.field.get_prep_lookup(lookup_type, value)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/related.py", line 143, in get_prep_lookup
    return self._pk_trace(value, 'get_prep_lookup', lookup_type)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/related.py", line 216, in _pk_trace
    v = getattr(field, prep_func)(lookup_type, v, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", line 322, in get_prep_lookup
    return self.get_prep_value(value)
  File "/usr/local/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", line 555, in get_prep_value
    return int(value)
ValueError: invalid literal for int() with base 10: 'c4adb615aa3c466185065997309e1c70'

[bruno@…]

This hardly qualifies as a bug : according to ​https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#specifying-a-custom-user-model contrib.auth expects your custom User model to have an integer primary key.

[edrobap]

Replying to bruno@…:

This hardly qualifies as a bug : according to ​https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#specifying-a-custom-user-model contrib.auth expects your custom User model to have an integer primary key.

You are right to point out that only interger primary key can be used in custom User model. But, this bug is not related to only User model. Let's say the models were:

from django.db import models
import uuid

class Publication(models.Model):
    title = models.CharField(max_length=30)

class Article(models.Model):
    id = models.CharField(primary_key=True, max_length=32, default=str(uuid.uuid4()).replace('-', ''))
    headline = models.CharField(max_length=100)
    publications = models.ManyToManyField(Publication)

You will still get the error. Any reverse m2m query will fail in these type of cases.

[Anssi Kääriäinen <akaariai@…>]

In 8b2c1ac06d3d1cf99661f4af75030abb456e1665:

Added tests for m2m queries with custom pk on the end models

It seems this case was fixed somewhere between 1.5.x and 1.6.x. I added
tests as I wasn't able to find any tests for these cases. Refs #21879

[Anssi Kääriäinen]

I wasn't able to reproduce this on master or 1.6.x. I added tests for this case as it seems there weren't any before.

If this error is only present only in 1.5.x we aren't going to fix it due to backporting policy. I'll close this as fixed, if there is still a bug in master/1.6.x we need more information to reproduce.