ProgrammingError: relation "django_content_type" already exists
3,686 views
Skip to first unread message
Mike Dewhirst
Mar 24, 2015, 2:00:28 AM3/24/15
to django...@googlegroups.com
This is my first stab at upgrading directly from Django 1.6.11 to 1.81c
to see what needs to be done. I thought I'd skip 1.7.x - is that a bad
idea? Is there some step in 1.7.x which eases the path to 1.8.x?
On first starting the project up using runserver on localhost it advises:
Python: 3.4
Django: 1.8c1
Database: ssds.climate.com.au
Postgres: 9.1
16:18:54
Performing system checks...
System check identified no issues (0 silenced).
You have unapplied migrations; your app may not work properly until they
are applied.
Run 'python manage.py migrate' to apply them.
See below. Not sure where to go from here. Any ideas?
Thanks
Mike
On running manage.py migrate it returns a ProgrammingError as follows:
(xxex3) C:\Users\mike\env\xxex3\ssds>python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: admindocs, messages, credit, refer,
company, workplace, staticfiles, substance, common
Apply all migrations: contenttypes, sessions, auth, sites, admin
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying contenttypes.0001_initial...Traceback (most recent call last):
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
psycopg2.ProgrammingError: relation "django_content_type" already exists
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 24, in <module>
execute_from_command_line(sys.argv)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\__init__.py",
line 338, in execute_from_command_line
utility.execute()
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\__init__.py",
line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\base.py",
line 390, in run_from_argv
self.execute(*args, **cmd_options)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\base.py",
line 441, in execute
output = self.handle(*args, **options)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\commands\migrate.py",
line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\executor.py",
line 94, in migrate
self.apply_migration(states[migration], migration, fake=fake,
fake_initial=fake_initial)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\executor.py",
line 131, in apply_migration
state = migration.apply(state, schema_editor)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\migration.py",
line 111, in apply
operation.database_forwards(self.app_label, schema_editor,
old_state, project_state)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\operations\models.py",
line 59, in database_forwards
schema_editor.create_model(model)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\base\schema.py",
line 282, in create_model
self.execute(sql, params or None)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\base\schema.py",
line 107, in execute
cursor.execute(sql, params)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Users\mike\env\xxex3\lib\site-packages\django\db\utils.py",
line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Users\mike\env\xxex3\lib\site-packages\django\utils\six.py",
line 658, in reraise
raise value.with_traceback(tb)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "django_content_type" already
exists
to see what needs to be done. I thought I'd skip 1.7.x - is that a bad
idea? Is there some step in 1.7.x which eases the path to 1.8.x?
On first starting the project up using runserver on localhost it advises:
Python: 3.4
Django: 1.8c1
Database: ssds.climate.com.au
Postgres: 9.1
16:18:54
Performing system checks...
System check identified no issues (0 silenced).
You have unapplied migrations; your app may not work properly until they
are applied.
Run 'python manage.py migrate' to apply them.
See below. Not sure where to go from here. Any ideas?
Thanks
Mike
On running manage.py migrate it returns a ProgrammingError as follows:
(xxex3) C:\Users\mike\env\xxex3\ssds>python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: admindocs, messages, credit, refer,
company, workplace, staticfiles, substance, common
Apply all migrations: contenttypes, sessions, auth, sites, admin
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying contenttypes.0001_initial...Traceback (most recent call last):
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
psycopg2.ProgrammingError: relation "django_content_type" already exists
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 24, in <module>
execute_from_command_line(sys.argv)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\__init__.py",
line 338, in execute_from_command_line
utility.execute()
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\__init__.py",
line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\base.py",
line 390, in run_from_argv
self.execute(*args, **cmd_options)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\base.py",
line 441, in execute
output = self.handle(*args, **options)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\core\management\commands\migrate.py",
line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\executor.py",
line 94, in migrate
self.apply_migration(states[migration], migration, fake=fake,
fake_initial=fake_initial)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\executor.py",
line 131, in apply_migration
state = migration.apply(state, schema_editor)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\migration.py",
line 111, in apply
operation.database_forwards(self.app_label, schema_editor,
old_state, project_state)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\migrations\operations\models.py",
line 59, in database_forwards
schema_editor.create_model(model)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\base\schema.py",
line 282, in create_model
self.execute(sql, params or None)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\base\schema.py",
line 107, in execute
cursor.execute(sql, params)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 64, in execute
return self.cursor.execute(sql, params)
File "C:\Users\mike\env\xxex3\lib\site-packages\django\db\utils.py",
line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Users\mike\env\xxex3\lib\site-packages\django\utils\six.py",
line 658, in reraise
raise value.with_traceback(tb)
File
"C:\Users\mike\env\xxex3\lib\site-packages\django\db\backends\utils.py",
line 62, in execute
return self.cursor.execute(sql)
django.db.utils.ProgrammingError: relation "django_content_type" already
exists
Mike Dewhirst
Mar 24, 2015, 3:54:22 AM3/24/15
to django...@googlegroups.com
Still not getting very far. The error below* keeps turning up. Further
to this, I ran migrate with --list and --settings=ssds.settings.dev and
it returns ...
admin
[ ] 0001_initial
auth
[ ] 0001_initial
[ ] 0002_alter_permission_name_max_length
[ ] 0003_alter_user_email_max_length
[ ] 0004_alter_user_username_opts
[ ] 0005_alter_user_last_login_null
[ ] 0006_require_contenttypes_0002
contenttypes
[ ] 0001_initial
[ ] 0002_remove_content_type_name
sessions
[ ] 0001_initial
sites
[ ] 0001_initial
The 1.7 docs say ...
The --list option will list all of the apps Django knows about, the
migrations available for each app and if they are applied or not (marked
by an [X] next to the migration name).
Apps without migrations are also included in the list, but will have (no
migrations) printed under them.
None of my five apps are listed.
Running makemigrations returns "No changes detected" so I suppose the
Django ones were done when I first ran manage.py migrate. That's only a
guess.
I'll keep reading the docs.
Thanks in advance
Mike
* see below
to this, I ran migrate with --list and --settings=ssds.settings.dev and
it returns ...
admin
[ ] 0001_initial
auth
[ ] 0001_initial
[ ] 0002_alter_permission_name_max_length
[ ] 0003_alter_user_email_max_length
[ ] 0004_alter_user_username_opts
[ ] 0005_alter_user_last_login_null
[ ] 0006_require_contenttypes_0002
contenttypes
[ ] 0001_initial
[ ] 0002_remove_content_type_name
sessions
[ ] 0001_initial
sites
[ ] 0001_initial
The 1.7 docs say ...
The --list option will list all of the apps Django knows about, the
migrations available for each app and if they are applied or not (marked
by an [X] next to the migration name).
Apps without migrations are also included in the list, but will have (no
migrations) printed under them.
None of my five apps are listed.
Running makemigrations returns "No changes detected" so I suppose the
Django ones were done when I first ran manage.py migrate. That's only a
guess.
I'll keep reading the docs.
Thanks in advance
Mike
* see below
manikos
Apr 9, 2015, 1:48:18 PM4/9/15
to django...@googlegroups.com
Hello Mike.
Today I took the road to upgrade from Django 1.6 --> 1.8. I wanted the bugfixes support and the long-term.
Everything looked good at the very beginning BUT it turned out that I get the same error with you, concerning the "django_content_type" already exists.
Have you found a solution to the problem?
Looking for your reply,
best regards,
nik
Today I took the road to upgrade from Django 1.6 --> 1.8. I wanted the bugfixes support and the long-term.
Everything looked good at the very beginning BUT it turned out that I get the same error with you, concerning the "django_content_type" already exists.
Have you found a solution to the problem?
Looking for your reply,
best regards,
nik
Mike Dewhirst
Apr 9, 2015, 6:43:40 PM4/9/15
to django...@googlegroups.com
Nik
Unfortunately no luck here. I'm staying with 1.6 until I can find the
time to establish a suite of dev sites each with their own database.
And I expect (now) that I'll go via 1.7 to 1.8.
I have been half hoping that someone else would discover the answer and
share it. If I solve it I'll certainly do that.
It is high on my todo list because it has to be done before the next
point release - which will omit 1.6.
Good luck
Mike
On 10/04/2015 3:41 AM, manikos wrote:
> Hello Mike.
>
> Today I took the road to upgrade from Django 1.6 --> 1.8. I wanted the
> bugfixes support and the long-term.
> Everything looked good at the very beginning BUT it turned out that I
> get the same error with you, concerning the "django_content_type"
> already exists.
> Have you found a solution to the problem?
>
> Looking for your reply,
> best regards,
> nik
>
> On Tuesday, March 24, 2015 at 8:00:28 AM UTC+2, Mike Dewhirst wrote:
>
> This is my first stab at upgrading directly from Django 1.6.11 to 1.81c
> to see what needs to be done. I thought I'd skip 1.7.x - is that a bad
> idea? Is there some step in 1.7.x which eases the path to 1.8.x?
>
> On first starting the project up using runserver on localhost it
> advises:
>
> Python: 3.4
> Django: 1.8c1
> Database: ssds.climate.com.au <http://ssds.climate.com.au>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/33a00654-229e-41eb-a2b4-88dfdbd08396%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/33a00654-229e-41eb-a2b4-88dfdbd08396%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
Unfortunately no luck here. I'm staying with 1.6 until I can find the
time to establish a suite of dev sites each with their own database.
And I expect (now) that I'll go via 1.7 to 1.8.
I have been half hoping that someone else would discover the answer and
share it. If I solve it I'll certainly do that.
It is high on my todo list because it has to be done before the next
point release - which will omit 1.6.
Good luck
Mike
On 10/04/2015 3:41 AM, manikos wrote:
> Hello Mike.
>
> Today I took the road to upgrade from Django 1.6 --> 1.8. I wanted the
> bugfixes support and the long-term.
> Everything looked good at the very beginning BUT it turned out that I
> get the same error with you, concerning the "django_content_type"
> already exists.
> Have you found a solution to the problem?
>
> Looking for your reply,
> best regards,
> nik
>
> On Tuesday, March 24, 2015 at 8:00:28 AM UTC+2, Mike Dewhirst wrote:
>
> This is my first stab at upgrading directly from Django 1.6.11 to 1.81c
> to see what needs to be done. I thought I'd skip 1.7.x - is that a bad
> idea? Is there some step in 1.7.x which eases the path to 1.8.x?
>
> On first starting the project up using runserver on localhost it
> advises:
>
> Python: 3.4
> Django: 1.8c1
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/33a00654-229e-41eb-a2b4-88dfdbd08396%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/33a00654-229e-41eb-a2b4-88dfdbd08396%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.
Mike Dewhirst
Apr 9, 2015, 7:05:43 PM4/9/15
to django...@googlegroups.com
Nik
See also my 6 April "KeyError: 'default'" thread
https://groups.google.com/forum/#!topic/django-users/U9y9_EeVyPE
It also involves contenttypes ...
> Creating test database for alias 'default'...
> line 19, in get_by_natural_key
> ct = self.__class__._cache[self.db][(app_label, model)]
> KeyError: 'default'
No luck there either.
Mike
See also my 6 April "KeyError: 'default'" thread
https://groups.google.com/forum/#!topic/django-users/U9y9_EeVyPE
It also involves contenttypes ...
> Creating test database for alias 'default'...
> Traceback (most recent call last):
> File
> "C:\Users\mike\env\xxex3\lib\site-packages\django\contrib\contenttypes\models.py",
> File
> line 19, in get_by_natural_key
> ct = self.__class__._cache[self.db][(app_label, model)]
> KeyError: 'default'
No luck there either.
Mike
Tim Graham
Apr 9, 2015, 8:40:56 PM4/9/15
to django...@googlegroups.com
Hi Mike,
Take a look at the migrate --fake-initial option. It's new in 1.8. In 1.7, --fake-initial was an implicit default, but we decided to make it explicit in 1.8.
https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial
Take a look at the migrate --fake-initial option. It's new in 1.8. In 1.7, --fake-initial was an implicit default, but we decided to make it explicit in 1.8.
https://docs.djangoproject.com/en/1.8/ref/django-admin/#django-admin-option---fake-initial
>> <mailto:django-users+unsub...@googlegroups.com>.
Adam Teale
Jun 16, 2015, 3:25:03 PM6/16/15
to django...@googlegroups.com
Hey guys did you manage to get anywhere with this?
Lenz
May 30, 2016, 5:57:33 PM5/30/16
to Django users
Thanks Tim! Running manage.py migrate --fake-initial solved the problem!
Reply all
Reply to author
Forward
0 new messages