On Fri, Dec 10, 2010 at 9:17 PM, TomPH <tgoel...@hatraco.de> wrote: > What is the best practise to migrate the data from sqllite to > postgres? All tries I had till now failed with DB key errors! > > What I did: > > 1) python manage.py dumpdata --indent 3 -n >../dev_data.json (dev. > system) > 2) python manage.py flush (production) > no creation of superusers (but this doesn't make any differne if I > create one or not...) > 3) python manage.py loaddata dev_data.json > > Error: > > Problem installing fixture '../dev_data.json': Traceback (most recent > call last): > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > core/management/commands/loaddata.py", line 172, in handle > obj.save(using=using) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > core/serializers/base.py", line 165, in save > models.Model.save_base(self.object, using=using, raw=True) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/models/base.py", line 500, in save_base > rows = manager.using(using).filter(pk=pk_val)._update(values) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/models/query.py", line 491, in _update > return query.get_compiler(self.db).execute_sql(None) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/models/sql/compiler.py", line 861, in execute_sql > cursor = super(SQLUpdateCompiler, self).execute_sql(result_type) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/models/sql/compiler.py", line 727, in execute_sql > cursor.execute(sql, params) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/backends/util.py", line 15, in execute > return self.cursor.execute(sql, params) > File "/usr/lib/python2.5/site-packages/Django-1.2.3-py2.5.egg/django/ > db/backends/postgresql/base.py", line 57, in execute > return self.cursor.execute(smart_str(sql, self.charset), > self.format_params(params)) > IntegrityError: ERROR: duplicate key error in Unique-Constraint > »django_content_type_app_label_key« > > UPDATE "django_content_type" SET "name" = 'Address Book', "app_label" > = 'contact', "model" = 'addressbook' WHERE "django_content_type"."id" > = 38 > > > I also dumped app by app and tried to load it - no success! Can > anybody post me the steps it normally should work? Maybe I forgot a > step (clear data or whatever in the target database...)?
You're hitting a common, and (now) easily resolved problem. The issue is that the content types table is automatically populated as part of the syncdb process. However, your fixture also contains content types data (since you're dumping the entire database). When you load the fixture into the new database, you get conflicts because the order of creation of content types isn't guaranteed, so your fixture is trying to produce duplicate content type records. The fix is reasonably simple. You need to do two things: 1) Omit content types from your dumped fixture 2) Use natural keys in your fixture. This ensures that any object that references a contenttype (e.g., user permissions) will load them by doing a lookup on the database, rather than just specifying a primary key value. So - your original dump command should look something like: ./manage.py dumpdata --exclude=contenttypes -n --indent=3 Your fixture should then load without incident on your synchronized Postgres database. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
