Una de las cosas que me molesta acerca de los accesorios Django es que debes especificar la clave principal de cada modelo. ¿Hay alguna manera de crear accesorios sin tener que especificar una clave principal para cada fila?Django: ¿Crear elementos sin especificar una clave principal?
Uso "pk: null" en lugar de "pk: 1" (o lo que sea), lo que se traducirá en el PK está establecido en Ninguno, y cuando el objeto se guarda, se asignará una clave principal.
Esto funciona para YAML al menos, supongo que estás usando eso si estás creando a mano.
Tienes que tener cuidado cuando usas accesorio sin pk. Al recuperar datos de carga, intentará agregar nuevas entradas en lugar de anular las existentes. – Danosaure
spookylukey o @Danosaure ¿Hay alguna forma de generar elementos "pk: null" utilizando manage.py dumpdata? Estoy consolidando dos DB con esquemas idénticos y estoy trabajando en cómo hacer esto con dumpdata/loaddata –
@BenRoberts El problema con pk: null es que puede terminar con duplicados. Normalmente solo dumpdata y vi el archivo para hacer este tipo de cosas. – Danosaure
Un amigo mío sugirió el módulo fixture: http://farmdev.com/projects/fixture/
Parece una pila justa de código repetitivo para trabajar. Mi flujo de trabajo para generar datos para la prueba es a menudo usar la interfaz de administración para crear datos, luego usar makeFIxture de django-test-utils para volcarlo en un archivo, y luego (si es necesario) anular cualquier entradas de pk –
Usted debe echar un vistazo a claves naturales si está calentársela añadir relación sin usar del pk
https://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata-app-label-app-label-app-label-model
Desafortunadamente, la docs en claves naturales no menciona el truco pk = null usado anteriormente. Necesitas ambas pk = null y las teclas naturales para tener un accesorio completamente sin pk. – Cerin
Desafortunadamente ese enlace ya no funciona. Aquí hay uno que funciona hoy, veamos si dura más de 3 años: https://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata-app-label-app-label-app-label-model –
que tenía que tratar con esquema de base de datos existente sin posibilidad de cambiarlo, así que necesito una tabla con clave primaria compleja o sin ella en absoluto, pero no con la clave de serie. Lo que hice:
he especificado un primary_key = true para el campo, que no debe ser único método en absoluto y escribió sobrecargado:
class ContraIndicationsMedicines(models.Model):
contra_indication = models.ForeignKey(ContraIndication, primary_key=True)
medicine = models.ForeignKey(Medicine)
def validate_unique(self, exclude=None):
pass
De hecho, funcionó para mis necesidades, pero hay más llamadas de validación dentro de django.contib.admin. * y no se garantiza que funcionen todas las líneas, etc. Esa fue la única solución que pude implementar ... ((
Si revisa el comando manage.py dumpdata, verá algunas opciones llamadas --natural-foreign, --natural-primary. Si mira en la salida, puede ver que los objetos se vuelcan sin utilizar claves principales o claves externas.
¿está utilizando manage.py --dumpdata o escribiendo a mano? –
Escribiéndolos a mano –