Code

Opened 6 years ago

Closed 5 years ago

#6408 closed (worksforme)

manage.py syncdb throwing error due content_types

Reported by: crybaby Owned by: nobody
Component: Core (Management commands) Version: 1.0
Severity: Keywords: manage.py syncdb content_types
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

I have django dev version 6941.

There seems to be a problem with manage.py line when I do python

'''manage.py syncdb''':
execute_manager(settings)


It creates the tables and but fails to populate initial data.

#!/usr/bin/env python
from django.core.management import execute_manager
try:

# This is for Dos Prompt Start up
    import  settings
except ImportError:
    import sys
    sys.stderr.write("Error: Can't find the file 'settings.py' in the
directory containing %r. It appears you've customized things.\nYou'll
have to run django-admin.py, passing it your settings module.\n(If the
file settings.py does indeed exist, it's causing an ImportError
somehow.)\n" % __file__)
    sys.exit(1)

if __name__ == "__main__":
    execute_manager(settings)

[joe@localhost mysite]$ python manage.py syncdb
Traceback (most recent call last):
  File "manage.py", line 15, in ?
    execute_manager(settings)
  File "/usr/lib/python2.4/site-packages/django/core/management/
__init__.py", line 272, in execute_manager
    utility.execute()
  File "/usr/lib/python2.4/site-packages/django/core/management/
__init__.py", line 219, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 72, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 86, in execute
    output = self.handle(*args, **options)
  File "/usr/lib/python2.4/site-packages/django/core/management/
base.py", line 168, in handle
    return self.handle_noargs(**options)
  File "/usr/lib/python2.4/site-packages/django/core/management/
commands/syncdb.py", line 95, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/usr/lib/python2.4/site-packages/django/core/management/
sql.py", line 489, in emit_post_sync_signal
    verbosity=verbosity, interactive=interactive)
  File "/usr/lib/python2.4/site-packages/django/dispatch/
dispatcher.py", line 358, in send
    sender=sender,
  File "/usr/lib/python2.4/site-packages/django/dispatch/
robustapply.py", line 47, in robustApply
    return receiver(*arguments, **named)
  File "/usr/lib/python2.4/site-packages/django/contrib/contenttypes/
management.py", line 21, in update_contenttypes
    content_types.remove(ct)
ValueError: list.remove(x): x not in list

I have commented out this from settings.py,
#'django.contrib.contenttypes',

and syncdb and fixtures are working.

I am currently running python 2.4.3 on Fedora 6 and django svn revision # 6980.

Attachments (0)

Change History (8)

comment:1 Changed 6 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

I can't reproduce this. Please post more info if you're still having this problem.

comment:2 Changed 6 years ago by lakin.wecker@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

My friend reproduced this recently on Mac OSX, 10.4 python 2.5 using an sqlite3 database and django trunk r7639. I have the copy of the code that produces it. The core issue is strange, but is due to [source:django/trunk/django/contrib/contenttypes/management.py#L11 django.contrib.contenttypes.management]

    ContentType.objects.clear_cache()
    content_types = list(ContentType.objects.filter(app_label=app.__name__.split('.')[-2]))

Apparently, the first call to objects.filter after a clear_cache() call will always return an empty list (even tho there are actually content_types in the database.) Duplicating the filter call (one right after the next) will fix the issue ... _or_, commenting out the clear_cache will also fix it. I suspect there is an underlying bug in the QuerySet caching on OSX and sqlite3. But I can't be totally sure. Given some guidance I'd be glad to try to track down the issue, but I don't have OSX in front of me right now.

comment:3 Changed 6 years ago by lakin.wecker@…

On the other hand, he may have a screwy python install. We're now seeing other wierdness from his django/python install and will be investigating it. Please feel free to re-close this ticket. If and when we figure out what's wrong we'll update here.

comment:4 Changed 6 years ago by russellm

  • Resolution set to invalid
  • Status changed from reopened to closed

Closed by request.

comment:5 Changed 6 years ago by lakin.wecker@…

So, my friend re-installed python from a binary and it seemed to clear up this issue for us.

comment:6 Changed 6 years ago by lakin.wecker@…

And apparently the python binary was 2.5.2, and he was running 2.5.1 when the problems were occuring.

comment:7 Changed 5 years ago by mpcabd

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from SVN to 1.0

I'm currently using Python 2.6 with Django 1.0 with MySQL 6.0.4 on a Windows XP and having the same problem.
I know I shouldn't use Windows but I'm developing on it now for a short period of time. :)

comment:8 Changed 5 years ago by russellm

  • Resolution set to worksforme
  • Status changed from reopened to closed

The original report was caused by a messed up Python install. If you're seeing "the same problem", then you also have a messed up Python install, and there's not much we can do. If you're seeing the same error message, it may not be the same cause, in which case you should open a new ticket with a complete set of instructions for reproducing the problem.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.