dumpscript dumps script but rundata doesn't process it

[GoogleCodeExporter]

What steps will reproduce the problem?
1. [In old project ]./manage.py dumpscript >> dump.db
2. [Move dump.db to new project] ./manage.py runscript dump.db

What is the expected output? What do you see instead?

It should work.  Instead, step 1 works fine (5 minutes to download 13MB of 
objects).  Step 2 
finishes in about a second and returns nothing.  No data is imported.

What version of the product are you using? On what operating system?

Django 1.0.2 on Fedora 10.  Python 2.5.2

Please provide any additional information below.

Original issue reported on code.google.com by arocki...@gmail.com on 7 Apr 2009 at 10:11

[GoogleCodeExporter]

BTW, I created a scripts/ directory and __init__.py as discussed in the wiki 
under dumpscript.

Original comment by arocki...@gmail.com on 7 Apr 2009 at 10:11

[GoogleCodeExporter]

This is the actual error.  I could only get this by manually going step by step 
through './manage.py shell'  First 
off, any fixtures will interfere with the runscript if you're doing a clean 
install with an existing data set and 
there are unique fields:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "<console>", line 7, in run
  File "/usr/lib/python2.5/site-packages/django/db/models/base.py", line 311, in save
    self.save_base(force_insert=force_insert, force_update=force_update)
  File "/usr/lib/python2.5/site-packages/django/db/models/base.py", line 383, in save_base
    result = manager._insert(values, return_id=update_pk)
  File "/usr/lib/python2.5/site-packages/django/db/models/manager.py", line 138, in _insert
    return insert_query(self.model, values, **kwargs)
  File "/usr/lib/python2.5/site-packages/django/db/models/query.py", line 894, in insert_query
    return query.execute_sql(return_id)
  File "/usr/lib/python2.5/site-packages/django/db/models/sql/subqueries.py", line 309, in execute_sql
    cursor = super(InsertQuery, self).execute_sql(None)
  File "/usr/lib/python2.5/site-packages/django/db/models/sql/query.py", line 1734, in execute_sql
    cursor.execute(sql, params)
  File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute
    return self.cursor.execute(sql, params)
  File "/usr/lib/python2.5/site-packages/django/db/backends/mysql/base.py", line 83, in execute
    return self.cursor.execute(query, args)
  File "/usr/lib/python2.5/site-packages/MySQLdb/cursors.py", line 166, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib/python2.5/site-packages/MySQLdb/connections.py", line 35, in defaulterrorhandler
    raise errorclass, errorvalue
IntegrityError: (1062, "Duplicate entry '8-add_logentry' for key 2")

Original comment by arocki...@gmail.com on 8 Apr 2009 at 2:19

[GoogleCodeExporter]

The wiki also mentions to run ./manage.py reset.
Are you running this against a DB where you have already ran syncdb?
If so, there are fixtures in django.contrib.auth and other various places that
automatically get inserted.  Maybe you need to run ./manage.py reset auth.

Or, you could wipe out the new DB completely and just run ./manage.py sql |
./manage.py dbshell to create the tables only.  Then maybe your dump script 
will work.

But, I think the real way that you're supposed to use it is application by 
application.

Disclaimer : I'm pretty new to django and django_extensions in general.

Original comment by Eric.Fre...@gmail.com on 21 Apr 2009 at 8:18

[GoogleCodeExporter]

Eric,  you are right that the fixtures in the auth class are interfering.  
You're also right that app by app is the best 
way to run this (as I've now learned).  Nonetheless there is no error handling 
in the script for duplicate keys - 
which is probably how I would edit the ticket (if I could).  Here is the 
related problem on the Django side:

http://code.djangoproject.com/ticket/7052

Original comment by arocki...@gmail.com on 22 Apr 2009 at 1:34