[1.1] Problem with unmanaged models and unit testing

[Tomasz Zieliński]

Hello

I have a problem with when trying to test app that is using unmanaged
models:

(...)
Creating table sometable
Traceback (most recent call last):
File "H:\myproject\manage.py", line 11, in <module>
execute_manager(settings)
File "C:\Python26\lib\site-packages\django\core\management
\__init__.py", line 362, in execute_manager
utility.execute()
File "C:\Python26\lib\site-packages\django\core\management
\__init__.py", line 303, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 195, in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 222, in execute
output = self.handle(*args, **options)
File "H:\myproject\south\management\commands\test.py", line 27, in
handle
super(Command, self).handle(*args, **kwargs)
File "C:\Python26\lib\site-packages\django\core\management\commands
\test.py", line 23, in handle
failures = test_runner(test_labels, verbosity=verbosity,
interactive=interactive)
File "C:\Python26\lib\site-packages\django\test\simple.py", line
191, in run_tests
connection.creation.create_test_db(verbosity, autoclobber=not
interactive)
File "C:\Python26\lib\site-packages\django\db\backends\creation.py",
line 336, in create_test_db
call_command('syncdb', verbosity=verbosity, interactive=False)
File "C:\Python26\lib\site-packages\django\core\management
\__init__.py", line 166, in call_command
return klass.execute(*args, **defaults)
File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 222, in execute
output = self.handle(*args, **options)
File "C:\Python26\lib\site-packages\django\core\management\base.py",
line 351, in handle
return self.handle_noargs(**options)
File "C:\Python26\lib\site-packages\django\core\management\commands
\syncdb.py", line 93, in handle_noargs
cursor.execute(statement)
File "C:\Python26\lib\site-packages\django\db\backends\mysql
\base.py", line 84, in execute
return self.cursor.execute(query, args)
File "C:\Python26\lib\site-packages\MySQLdb\cursors.py", line 166,
in execute
self.errorhandler(self, exc, value)
File "C:\Python26\lib\site-packages\MySQLdb\connections.py", line
35, in defaulterrorhandler
raise errorclass, errorvalue
_mysql_exceptions.OperationalError: (1005, "Can't create table
'test_myproject.#sql-710_139' (errno: 150)")


Table name #sql-710_139 doesn't make sense, so it's doesn't look to me
like something I could do wrong.

Has some of you an idea of what's going on here?

--
Tomasz Zieliński
http://pyconsultant.eu

[Russell Keith-Magee]

2009/11/14 Tomasz Zieliński <tomasz.z...@pyconsultant.eu>:

In short, no. The stack trace by itself doesn't give much of a hint
either - I can't think of any circumstance where Django would be
trying to create a table called #sql-710_139. In order to help our
here, we'd need to see the code for a full project that demonstrates
the problem.

Yours,
Russ Magee %-)

[Craig Kimerer]

Probably a constraint problem on the tables being created.  Logging into to your MySQL server via command line and running either 'show myisam status' or 'show innodb status' (depending on what type of tables you are making) should provide you with more useful information.

Craig

--

You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=.

[Tomasz Zieliński]

Thank you for you responses, I think I spotted the problem.

My unmanaged model is in fact wrapper for database view.
It also inherits from Django abstract model that has ManyToManyField-s
onboard.

When trying to test my app, syncdb.py in line 93 tries to actually add
foreign key
pointing from m2m intermediate table to unmanaged model's table, which
of course
doesn't exist (in my regular app db views are pre-created manually).

BTW string ' #sql-710_139' doesn't appear in sql statement that causes
mentioned error,
the statement is perfectly ok.

--
Tomasz Zielinski
http://pyconsultant.eu