Solución:
Como se ve en la documentación, desde Django 1.8 hay un campo UUID integrado. Las diferencias de rendimiento cuando se usa un UUID frente a un número entero son insignificantes.
import uuid
from django.db import models
class MyUUIDModel(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
También puede consultar esta respuesta para obtener más información.
Una clave primaria UUID causará problemas no solo con las relaciones genéricas, sino con la eficiencia en general: cada clave externa será significativamente más cara, tanto para almacenar como para unir, que una palabra de máquina.
Sin embargo, nada requiere que el UUID sea la clave principal: simplemente conviértalo en secundario clave, complementando su modelo con un campo uuid con unique=True
. Use la clave primaria implícita como de costumbre (interna a su sistema) y use el UUID como su identificador externo.
Me encontré con una situación similar y descubrí en la documentación oficial de Django, que el object_id
no tiene que ser del mismo tipo que el Clave primaria del modelo relacionado. Por ejemplo, si desea que su relación genérica sea válida para ambos IntegerField y CharField ID, solo configure su object_id
ser un CharField. Dado que los enteros pueden coaccionarse en cadenas, estará bien. Lo mismo vale para UUIDField.
Ejemplo:
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)