South blows a tire when it hits db.delete_unique('django_template', ['name']) in the second migration in dbtemplates using MySQL. Is this constraint really necessary to remove?
(app)[user@web313 src]$ python manage.py migrate
Running migrations for dbtemplates:
- Migrating forwards to 0002_auto__del_unique_template_name.
> dbtemplates:0002_auto__del_unique_template_name
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: = ALTER TABLE `django_template` ADD CONSTRAINT `django_template_name_uniq` UNIQUE (`name`) []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS.
! NOTE: The error which caused the migration to fail is further up.
Traceback (most recent call last):
File "manage.py", line 14, in <module>
execute_manager(settings)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
output = self.handle(*args, **options)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/management/commands/migrate.py", line 105, in handle
ignore_ghosts = ignore_ghosts,
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/__init__.py", line 191, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 221, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 292, in migrate_many
result = self.migrate(migration, database)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 125, in migrate
result = self.run(migration)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 99, in run
return self.run_migration(migration)
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 81, in run_migration
migration_function()
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/migration/migrators.py", line 57, in <lambda>
return (lambda: direction(orm))
File "/home/user/.virtualenvs/app/src/django-dbtemplates/dbtemplates/migrations/0002_auto__del_unique_template_name.py", line 12, in forwards
db.delete_unique('django_template', ['name'])
File "/home/user/.virtualenvs/app/lib/python2.7/site-packages/south/db/generic.py", line 479, in delete_unique
raise ValueError("Cannot find a UNIQUE constraint on table %s, columns %r" % (table_name, columns))
ValueError: Cannot find a UNIQUE constraint on table django_template, columns ['name']
Hi,
First, thanks for putting this out there - I plan on using it or some variant, but am running in to issues with multiple sites. There are two 'modes' of use of django.contrib.sites - the original (SITE_ID = ) and 'by request' (no SITE_ID). Some packages make use of the second method, things like allauth for social authentication, for instance. I intend to run my site this way and like the way dbtemapltes is set up, but cannot run because of the dependancy to SITE_ID.
Unfortunately, loaders don't have access to the request for good reason, they may be used elsewhere.
One way I can solve this is with a 5-6 line patch to django itself. I have proposed this to the django development group with muted response, but without outright "won't fix" ("maybe, someday"). No comments yet.
Alternately, I may modify this thing to take a setting if present, otherwise call get_current. I believe this would create a version of dbtemplates which works identically for all installations currently using SITE_ID and allow friendly operation with "by_request". As far as I can see, the only catch is making sure settings.DBTEMPALTES_SITE_ID is in the M2M for all templates.
This scheme would effectively combine the template namespace to the 'main', but I'll probably just string mash the site pk in to the template name under the hood.
Thoughts? Should I go to the effort to try to generalize and prepare a pull request?
Regards,
Ira