On Sun, Mar 8, 2009 at 2:24 PM, He Jibo <[email protected]> wrote: > Dear All, > > I ran into the following error of "IntegrityError: columns app_label, model > are not unique" when I tried to > Sync the data to the db with the command of "manage.py syncdb". I am using > python2.5, Django-1.0.2-final, and Window XP. > > Could anyone be kindly to tell me how to solve this problem? Thank you so > much ! ... > Installing json fixture 'initial_data' from '/Users/ucantblamem/Sites/ > django-page-cms/pages/fixtures'. > > Problem installing fixture '/Users/ucantblamem/Sites/django-page-cms/pages/ > fixtures/initial_data.json': Traceback (most recent call last): > File "/Library/Python/2.5/site-packages/django/core/management/commands/ > > loaddata.py", line 112, in handle > obj.save() > File "/Library/Python/2.5/site-packages/django/core/serializers/ > base.py", line 170, in save > models.Model.save_base(self.object, raw=True) > > File "/Library/Python/2.5/site-packages/django/db/models/base.py", line > 320, in save_base > manager.filter(pk=pk_val)._update(values) > File "/Library/Python/2.5/site-packages/django/db/models/query.py", line > > 420, in _update > query.execute_sql(None) > File "/Library/Python/2.5/site-packages/django/db/models/sql/ > subqueries.py", line 112, in execute_sql > super(UpdateQuery, self).execute_sql(result_type) > > File "/Library/Python/2.5/site-packages/django/db/models/sql/query.py", > line 1608, in execute_sql > cursor.execute(sql, params) > File "/Library/Python/2.5/site-packages/django/db/backends/util.py", > > line 18, in execute > return self.cursor.execute(sql, params) > File "/Library/Python/2.5/site-packages/django/db/backends/sqlite3/ > base.py", line 144, in execute > return Database.Cursor.execute(self, query, params) > > IntegrityError: columns app_label, model are not unique >
This indicates a subtle problem with your fixture. Avoiding this problem is the subject of ticket #7052. Unfortunately, it's not a easy problem to solve. The problem is a conflict between your fixture and the process of adding the 'django.contrib.auth' and/or 'django.contrib.contenttype' applications. contrib.auth and contrib.contenttypes dynamically create data when they are synchronized into your database. When you create a database dump using dumpdata, these dynamically created types are included in the dump, and so they conflict when you try to load the dump into a new database. In your specific case, the problem appears to be a contenttype - the fixture is specifying a new content type that has already been dynamically created in the database. There isn't a simple solution (e.g., enable option -foo) for this problem. The relatively simple solution that _might_ work (depending on the details of your project) is to remove references to contrib.auth and contrib.contenttypes in your fixture. You can do this manually by deleting the parts of the fixture that reference contrib.auth and contrib.contenttypes. Alternatively, if you have access to the original data source, you can use the --exclude option to dumpdata: http://docs.djangoproject.com/en/dev/ref/django-admin/?from=olddocs#djadminopt--exclude However, this approach won't work if your project contains contenttype references. The most common source of these would be if you were using a GenericForeignKey in your project. The long term solution for this problem involves introducing the ability to dynamically lookup contenttypes in a fixture. However, while there are some prototypes of this approach floating around in the community, there isn't a implementation of this that I can easily point you to. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
