使用UUID作为Django模型中的主键（通用关系影响）
出于多种原因^，我想在我的一些Django模型中使用UUID作为主键。 如果我这样做，我仍然可以使用外部应用程序，如“contrib.comments”，“Django-voting”或“Django-tagging”，通过ContentType使用generics关系？
以“django-voting”为例，Vote模型如下所示：
class Vote(models.Model): user = models.ForeignKey(User) content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() object = generic.GenericForeignKey('content_type', 'object_id') vote = models.SmallIntegerField(choices=SCORES) 这个应用程序似乎假设被投票的模型的主键是一个整数。
内置的评论应用程序似乎能够处理非整数PK，但：
class BaseCommentAbstractModel(models.Model): 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")
这是“整数PK假设”的问题是第三方应用程序的常见情况，这将使使用UUID痛苦？ 或者，我可能会误读这种情况吗？
有没有办法在Django中使用UUID作为主键而不会造成太大麻烦？
^一些原因：隐藏对象计数，防止url“ID爬行”，使用多个服务器创build非冲突的对象，…
一个UUID主键不仅会引起一般关系的问题，而且会带来一些问题：每个外键在存储和join方面都会比一个机器语言贵得多。
然而，没有什么要求UUID成为主键：只要将它作为辅助键，通过用unique=True的uuid字段补充模型。 正常使用隐式主键（系统内部），并使用UUID作为外部标识符。
Django 1.8现在有一个内置的UUID字段。 使用UUID与整数时的性能差异可以忽略不计。
import uuid from django.db import models class MyUUIDModel(models.Model): id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
我遇到了类似的情况，并在官方的Django文档中发现， object_id不必与相关模型的primary_key具有相同的types。 例如，如果您希望您的通用关系对于IntegerField和CharField ID都是有效的，只需将您的object_id设置为CharField即可 。 由于整数可以胁迫string，它会没事的。 UUIDField也一样 。
例：
class Vote(models.Model): user = models.ForeignKey(User) content_type = models.ForeignKey(ContentType) object_id = models.CharField(max_length=50) # <<-- This line was modified object = generic.GenericForeignKey('content_type', 'object_id') vote = models.SmallIntegerField(choices=SCORES)
