views:

66

answers:

1

I am working to use django's ContentType framework to create some generic relations for a my models; after looking at how the django developers do it at django.contrib.comments.models I thought I would imitate their approach/conventions:

from django.contrib.comments.models, line 21):

content_type   = models.ForeignKey(ContentType,
        verbose_name='content type',
        related_name="content_type_set_for_%(class)s")
object_pk      = models.TextField('object ID')
content_object = generic.GenericForeignKey(ct_field="content_type", fk_field="object_pk")

That's taken from their source and, of course, their source works for me (I have comments with object_pk's stored just fine (integers, actually); however, I get an error during syncdb on table creation that ends:

_mysql_exceptions.OperationalError: (1170, "BLOB/TEXT column 'object_pk' used in key specification without a key length")

Any ideas why they can do it and I can't ?

After looking around, I noticed that the docs actually state:

Give your model a field that can store a primary-key value from the models you'll be relating to. (For most models, this means an IntegerField or PositiveIntegerField.)

This field must be of the same type as the primary key of the models that will be involved in the generic relation. For example, if you use IntegerField, you won't be able to form a generic relation with a model that uses a CharField as a primary key.

But why can they do it and not me ?!

Thanks.

PS: I even tried creating an AbstractBaseModel with these three fields, making it abstract=True and using that (in case that had something to do with it) ... same error.

A: 

After I typed out that really long question I looked at the mysql and realized that the error was stemming from:

class Meta:
    unique_together = (("content_type", "object_pk"),)

Apparently, I can't have it both ways. Which leaves me torn. I'll have to open a new question about whether it is better to leave my object_pk options open (suppose I use a textfield as a primary key?) or better to enforce the unique_togetherness...

thornomad