Las fixtures de Django son una forma muy cómoda de disponer de datos en formatos legibles por humanos e independientes de la base de datos que se utilice. Son fáciles de crear y de cargar, pero tienen varios inconvenientes. En Django 1.2 se ha solucionado uno de sus mayores problemas: cuando las fixtures dejan de ser válidas porque hay referencias a instancias con claves primarias que cambian respecto de lo que indican las fixtures.

Un caso típico es que se crean fixtures de un proyecto, y algunos modelos de datos hacen referencia a ContentType (django.contrib.contentype.models.ContentType). Django genera dinámicamente un ContentType por cada modelo de datos existente en un proyecto al ejecutar syncdb, pero las claves primarias de los ContentType pueden ser (y serán) diferentes a medida que se crean y eliminan modelos en el proyecto. Por tanto las fixtures creadas en una instantánea del proyecto probablemente deje de funcionar en el futuro porque habrá referencias erróneas a los ContentType.

La solución incluida en Django 1.2 son las "natural keys" (claves naturales de ahora en adelante). La idea es, en vez de referenciar esas instancias por su clave primaria

"content_type": 37

usamos un conjunto de atributos que identifica unívocamente una instancia:

"content_type": ["library", "book"]

En el caso de ContentType su clave natural está compuesta de la aplicación ("library") y el modelo de datos ("book").

Las claves naturales no son algo exclusivo de ContentType, sino que pueden incluirse en cualquier modelo de datos, simplemente añadiendo un método get_natural_key() al modelo y otro método get_by_natural_key() a su manager. Por ejemplo:

Claves naturales en la documentación de Django: http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys