Wygląda na to, że django dumpdata zrzuciło urządzenia w złej kolejności. Zajrzyj do pliku json, aby sprawdzić, czy product z id: 1 jest tam obecny. Jeśli, jak przypuszczam, to prawda, użyj bardziej wyrafinowanych narzędzi do zrzutu danych, na przykład django-fixture-magic
Alternatywnie, możesz chcieć usunąć wszystkie ograniczenia integralności za pomocą silnika bazy danych tuż przed przesłaniem i spróbować je odtworzyć zaraz po, ale jest to nieco ryzykowne, jeśli pojawią się błędy integralności.
W przypadku PostgreSQL zapoznaj się z tym wątkiem wiedzieć, jak uzyskać definicje tabel. W MySQL wyglądałoby to tak:
$ mysqldump --no-data -utest django auth_user_user_permissions
CREATE TABLE `auth_user_user_permissions` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`permission_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `user_id` (`user_id`,`permission_id`),
KEY `auth_user_user_permissions_403f60f` (`user_id`),
KEY `auth_user_user_permissions_1e014c8f` (`permission_id`),
CONSTRAINT `user_id_refs_id_dfbab7d` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`),
CONSTRAINT `permission_id_refs_id_67e79cb` FOREIGN KEY (`permission_id`) REFERENCES `auth_permission` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Poniższa część powinna działać dla oracle, postgre i mysql
> alter table `auth_user_user_permissions` drop foreign key `user_id_refs_id_dfbab7d`;
Query OK, 0 rows affected (0.97 sec)
Records: 0 Duplicates: 0 Warnings: 0
> alter table `auth_user_user_permissions` add CONSTRAINT `user_id_refs_id_dfbab7d` FOREIGN KEY (`user_id`) references `auth_user` (`id`);
Query OK, 0 rows affected (0.95 sec)
Records: 0 Duplicates: 0 Warnings: 0
