south-migration-multiple-databases-problem
文件大小: unknow
源码售价: 5 个金币 积分规则     积分充值
资源说明:Demonstration of the bug described at: https://groups.google.com/forum/?fromgroups=#!topic/south-users/Sre6bO9aJzo
I'm having problems running tests on a project with multiple databases. It 
seems that the testcase setup fails before it ever reaches my code, 
because the south_migrationhistory table only exists in one database, but 
South expects to find it in all databases. 

The bug is under discussion on the [South mailing list](https://groups.google.com/forum/?fromgroups=#!topic/south-users/Sre6bO9aJzo).

You can repro this problem using this demo app, like this:

	git clone git@github.com:qris/south-migration-multiple-databases-problem.git
	cd south-migration-multiple-databases-problem
	virtualenv ve
	ve/bin/pip install -r pip_packages.txt
	ve/bin/python migration_multiple_databases_problem/manage.py test app1

This is part of the stack trace leading to the failure: 

	-> failures = test_runner.run_tests(test_labels) 
	   django-1.5/django/test/simple.py(367)run_tests() 
	-> old_config = self.setup_databases() 
	   django-1.5/django/test/simple.py(315)setup_databases() 
	-> self.verbosity, autoclobber=not self.interactive) 
	   ischool_user_manager/.ve/local/lib/python2.7/site-packages/south/hacks/django_1_0.py(100)wrapper() 
	-> f(*args, **kwargs) 
	   django-1.5/django/db/backends/creation.py(293)create_test_db() 
	-> load_initial_data=False) 
	   django-1.5/django/core/management/__init__.py(160)call_command() 
	-> return klass.execute(*args, **defaults) 
	   django-1.5/django/core/management/base.py(252)execute() 
	-> output = self.handle(*args, **options) 
	   django-1.5/django/core/management/base.py(382)handle() 
	-> return self.handle_noargs(**options) 
	   ischool_user_manager/.ve/local/lib/python2.7/site-packages/south/management/commands/syncdb.py(99)handle_noargs() 
	-> management.call_command('migrate', **options) 
	   django-1.5/django/core/management/__init__.py(160)call_command() 
	-> return klass.execute(*args, **defaults) 
	   django-1.5/django/core/management/base.py(252)execute() 
	-> output = self.handle(*args, **options) 
	   ischool_user_manager/.ve/local/lib/python2.7/site-packages/south/management/commands/migrate.py(108)handle() 
	-> ignore_ghosts = ignore_ghosts, 
	> ischool_user_manager/.ve/local/lib/python2.7/site-packages/south/migration/__init__.py(175)migrate_app() 
	-> south.db.db.debug = (verbosity > 1) 

django/test/simple.py:setup_databases() is looping over all databases that 
are not marked as TEST_MIRRORs, in the second pass loop. It calls 
create_test_db() on each one, which calls the syncdb management command, 
which South intercepts in order to call migrate. 

This is doing a query for MigrationHistory objects in the database that's 
currently being created: 

	applied_all = MigrationHistory.objects.filter(applied__isnull=False).order_by('applied').using(database) 

But if the database that we're creating is not the same one that 
MigrationHistory objects are routed to, then this will throw an uncaught 
exception: 

	DatabaseError: no such table: south_migrationhistory 

A workaround in my case is to mark all databases except the default one as 
TEST_MIRRORs. But that won't work for everyone. 

Does anyone know whether MigrationHistory is supposed to be sharded across 
all non-mirror databases? If so, then we have to be careful when writing 
our database routers to allow it to syncdb in all databases, which is not 
intuitive. Perhaps it's the true solution in our case. 

Perhaps it would be helpful if we trap this DatabaseError in South, and 
raise a more helpful exception? 

本源码包内暂不包含可直接显示的源代码文件,请下载源码包。