__group__ ticket summary component milestone type created _description_ _changetime _reporter andrew 32 ContentType table is not updated when renaming table migrations The Future defect 2008-10-21T14:05:47+01:00 "When a table is renamed, the ContentType table is not updated, causing existing generic relations to fail. " 2009-11-07T16:56:34Z e.t.j.scheffers@… andrew 87 migrating models from an abstract model class commands The Future defect 2009-02-27T04:46:45Z "Hi Fellows, Commendations upon South, I LOVE IT. However, I had no luck with adding a column to the base abstract model class, of which there are three slightly different inherited model classes. Does it work?" 2011-10-08T08:27:01+01:00 Antonius Common andrew 994 add_column(PositiveIntegerField, keep_default=False) create greater zero constraint twice commands 1.0 defect 2012-01-16T15:59:22Z "If you use keep_default=False for add_column of a PositiveIntegerField, the check constraint gets created twice. You can reproduce it like this: Modify tests/db.py {{{ diff -r 2f9a84a48350 south/tests/db.py --- a/south/tests/db.py Fri Jan 13 13:34:00 2012 +0000 +++ b/south/tests/db.py Mon Jan 16 16:56:47 2012 +0100 @@ -258,6 +258,14 @@ val = db.execute(""SELECT user_id FROM test_addc"")[0][0] self.assertEquals(val, None) db.delete_column(""test_addc"", ""add1"") + + db.add_column(""test_addc"", ""num_positive"", models.PositiveIntegerField(default=0), keep_default=False) + db.commit_transaction() + db.start_transaction() + import sys + print 'Inspect DB now. For postgres psql test_.... \d test_addc' + sys.stdin.readline() + db.delete_table(""test_addc"") def test_add_nullbool_column(self): }}} Inspect the db before while scripts waits for input: {{{ Check-Constraints: ""ck_num_positive_pstv_2ef4ccd14d7211b6"" CHECK (num_positive >= 0) ""test_addc_num_positive_check"" CHECK (num_positive >= 0) }}} If you don't supply keep_default=False, then there is only one constraint. Versions: {{{ PostgreSQL 8.4.8 on x86_64-unknown-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292], 64-bit Python 2.6 }}} " 2012-01-16T16:03:05Z guettli andrew 1024 retry_failed_fields methods fails to produce meaningfull error if exception message contains unicode chars commands 1.0 defect 2012-02-05T10:27:30Z "Method `south.orm.FakeOrm.retry_failed_field` fails to produce meaningfull error if field raises exception that contains unicode chars during creation. Faulty code is {{{ try: field = self.eval_in_context(code, app, extra_imports) except (NameError, AttributeError, AssertionError, KeyError), e: # It's failed again. Complain. raise ValueError(""Cannot successfully create field '%s' for model '%s': %s."" % ( fname, modelname, e )) }}} You should either use unicode pattern: {{{ raise ValueError(u""Cannot successfully create field '%s' for model '%s': %s."" % ( fname, modelname, e )) }}} or use repr: {{{ raise ValueError(u""Cannot successfully create field '%s' for model '%s': %s."" % ( fname, modelname, repr(e) )) }}} Full stack trace: {{{ Traceback (most recent call last): File ""/home/jb/ides/pycharm-2.0.1/helpers/pydev/pydevd.py"", line 1325, in debugger.run(setup['file'], None, None) File ""/home/jb/ides/pycharm-2.0.1/helpers/pydev/pydevd.py"", line 1033, in run pydev_imports.execfile(file, globals, locals) #execute the script File ""/home/jb/programs/drat/hajmon/hajmondjango/manage.py"", line 15, in execute_manager(settings) File ""/usr/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/usr/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/usr/lib/python2.6/dist-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/lib/python2.6/dist-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 93, in run south.db.db.current_orm = self.orm(migration) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 246, in orm return migration.orm() File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/utils.py"", line 62, in method value = function(self) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/base.py"", line 422, in orm return FakeORM(self.migration_class(), self.app_label()) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py"", line 46, in FakeORM _orm_cache[args] = _FakeORM(*args) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py"", line 132, in __init__ self.retry_failed_fields() File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/orm.py"", line 371, in retry_failed_fields fname, modelname, e }}}" 2012-02-05T11:53:03Z jbzdak@… andrew 1049 unique_together ordering commands 1.0 defect 2012-03-05T15:42:51Z "I am trying to add a unique_together constraint to a table. The fields are listed in specific order, because the index that is created will perform properly only if the fields are in that order. So South needs to respect the order given in each tuple. The fields are coming out in the right order in the freezer, so it must be something after that I guess (changes.py?). " 2012-06-26T21:54:42+01:00 George Lund andrew 1073 South does not notice when a ForeignKey's type should change commands The Future defect 2012-05-04T15:52:04+01:00 "If I create ModelA which has a primary key set to a CharField, and create a ForeignKey from ModelB to ModelA, this works fine. If I then change the ForeignKey to ModelC, which has an integer primary key, but I don't rename the foreign key field, south doesn't notice." 2012-05-04T16:03:11+01:00 anonymous andrew 579 Field name not updated on ManyToMany through table migrations 1.0 defect 2010-09-13T02:09:07+01:00 "I changed the model that a ManyToMany field pointed to after the 'through' table already existed and deleted the old model. The through table field name still reflects the name of the old model even after schema migration. Opening the migrations before and after the change, I see that the variable models has been updated to reflect the change. Adding a list of model objects to the ManyToMany field will fail because Django will expect the field name in the 'through' table to be that of the new model, and you get an error like: _mysql_exceptions.OperationalError OperationalError: (1054, ""Unknown column 'user_id' in 'field list'"") Thanks!" 2010-12-01T19:56:28Z thomas.paul.matthews@… andrew 958 Django-south test management commands breaks ability to use Nose coverage options commands 1.0 defect 2011-11-21T14:05:11Z "Howdy, Just run into a problem where after installing South I was no longer to run my unit tests through the Django test management command and still use the most excellent coverage package. Specifically, trying to run: % python manage.py test --with-coverage Would fail, saying that --with-coverage was an unknown option. Some digging around leads to a rabbit hole of South and Nose both overloading each other, but ultimately comes down to the option_list for the command not including extra options from a custom TestRunner. (Nose's test runner in this case) In any case, for my install I fixed it by overloading the test management command yet again, in the same manner Nose does, to a sum total of the code below. This seems to play nicely regardless of which test runner is being used. Hope it helps, Cheers, -Nic ----- from django.core.management.commands import test from south.management.commands import patch_for_test_db_setup from django.test.utils import get_runner from django.conf import settings TestRunner = get_runner(settings) if hasattr(TestRunner, 'options'): extra_options = TestRunner.options else: extra_options = [] class Command(test.Command): option_list = test.Command.option_list + tuple(extra_options) def handle(self, *args, **kwargs): patch_for_test_db_setup() super(Command, self).handle(*args, **kwargs) " 2013-04-24T21:49:25+01:00 nicp@… andrew 992 Primary Key: SlugField to CharField migrations 1.0 defect 2012-01-13T11:45:03Z "I changed a SlugField to CharField of a primary key. {{{ # models.py class EmailSender(models.Model): - id=models.SlugField(primary_key=True) + id=models.CharField(primary_key=True, max_length=50, validators=[RegexValidator(r'^[a-zA-Z0-9_.-]+$')]) }}} The migration created with --auto looks like this: {{{ #migration class Migration(SchemaMigration): def forwards(self, orm): # Changing field 'EmailSender.id' db.alter_column('modwork_emailsender', 'id', self.gf('django.db.models.fields.CharField')(max_length=50, primary_key=True)) # Removing index on 'EmailSender', fields ['id'] db.delete_index('modwork_emailsender', ['id']) }}} {{{ psql \d modwork_emailsender modwork_tbz_d=> \d modwork_emailsender Table ""public.modwork_emailsender"" Column | Type | Modifiers --------+-----------------------+----------- id | character varying(50) | not null email | character varying(75) | not null footer | text | Indexes: ""modwork_emailsender_pkey"" PRIMARY KEY, btree (id) ""modwork_emailsender_email_uniq"" UNIQUE, btree (email) }}} 2012-01-13 10:04:36 generic: DEBUG south execute ""DROP INDEX ""modwork_emailsender_id"""" with params ""[]"" django.db.utils.DatabaseError: ERROR: Index »modwork_emailsender_id« does not exist I removed the ""delete_index()"" and the migration was successfull. south version: {{{ hg summary parent: 997:fcf464bd036f tip Fixed the timezone handling by simply converting the timezone aware datetime object into a naive version with the help of the default timezone (aka settings.TIME_ZONE). branch: default commit: 1 unknown (clean) update: (current) }}} Related: http://groups.google.com/group/south-users/browse_thread/thread/90ca1d17285df720/33b1c6233f06f1c8?show_docid=33b1c6233f06f1c8" 2012-01-13T11:48:06Z guettli andrew 1050 converstion of IntegerField to PositiveIntegerField has constraint problems migrations 1.0 defect 2012-03-05T20:13:31Z "I had an IntegerField that I converted to a PositiveIntegerField, the auto detector sees the change and makes some SQL changes that are over my head, so I'm not sure exactly what it is attempting to do, but the end result upon inspecting the database is that there is no constraint in place. If I create a new PositiveIntegerField, the column created is ""integer"" (in my case NOT NULL), the constraint is ""fieldname >= 0"". If I create an IntegerField and convert it to a PositiveIntegerField no constraint shows up. Running on South 0.7.3, using Postgres 9.1, Django 1.3. Output from running migration is: execute: south execute "" SELECT kc.constraint_name, kc.column_name FROM information_schema.constraint_column_usage AS kc JOIN information_schema.table_constraints AS c ON kc.table_schema = c.table_schema AND kc.table_name = c.table_name AND kc.constraint_name = c.constraint_name WHERE kc.table_schema = %s AND kc.table_name = %s AND c.constraint_type = %s "" with params ""['public', 'proxy_rule', 'CHECK']"" execute: south execute "" SELECT kc.constraint_name, kc.column_name FROM information_schema.key_column_usage AS kc JOIN information_schema.table_constraints AS c ON kc.table_schema = c.table_schema AND kc.table_name = c.table_name AND kc.constraint_name = c.constraint_name WHERE kc.table_schema = %s AND kc.table_name = %s AND c.constraint_type = %s "" with params ""['public', 'proxy_rule', 'FOREIGN KEY']"" execute: south execute ""ALTER TABLE ""proxy_rule"" ALTER COLUMN ""testagain"" TYPE integer, ALTER COLUMN ""testagain"" SET NOT NULL, ALTER COLUMN ""testagain"" DROP DEFAULT;"" with params ""[]"" In above, the ""testagain"" is the field I converted." 2012-03-05T22:10:31Z ctrudeau@… andrew 1076 "MySQL: delete_unique() fails if the index ""supports"" a FK" migrations 1.0 defect 2012-05-09T20:39:13+01:00 "I'll paraphrase a mail I recently sent to the transifex-devel list In (at least) MySQL 5.0.x and 5.1.x, foreign keys need to be ""supported"" by an index. If the user explicitly adds an index, MySQL will use that one. MySQL will not allow the index to be dropped. This is a problem for the following automatically-generated migration: (Ref: https://github.com/transifex/transifex/blob/1.2/transifex/addons/webhooks/migrations/0002_allow_many_hooks_to_a_project.py) {{{ def forwards(self, orm): # Removing unique constraint on 'WebHook', fields ['project'] db.delete_unique('webhooks_webhook', ['project_id']) # Changing field 'WebHook.project' db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project'])) }}} The call to delete_unique() causes a mysterious MySQL error (I believe they have changed it to something more user-friendly in later releases): {{{ _mysql_exceptions.OperationalError: (1025, ""Error on rename of '.\\tfex\\#sql-27f0_16' to '.\\tfex\\webhooks_webhook' (errno: 150)"") }}} One fix for transifex is to hand-modify the migration like so: {{{ def forwards(self, orm): # Removing unique constraint on 'WebHook', fields ['project'] + # Remove the foreign key to avoid problems with MySQL; it'll get recreated. + db.delete_foreign_key('webhooks_webhook', 'project_id') db.delete_unique('webhooks_webhook', ['project_id']) # Changing field 'WebHook.project' db.alter_column('webhooks_webhook', 'project_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['projects.Project'])) }}} I suppose another possiblity is for MySQL's delete_unique to get a little smarter. " 2012-10-02T12:21:42+01:00 paul.dubois@… andrew 1109 m2m tables greted twice commands The Future defect 2012-06-06T15:38:00+01:00 "This creates the m2m table twice. This is idiomatic if you want the relation to show up bidirectionally in the admin or in autogenerated forms; cf. [https://code.djangoproject.com/ticket/897] {{{ class Test1(models.Model): tests2 = models.ManyToManyField('Test2', blank=True) class Test2(models.Model): tests1 = models.ManyToManyField(Test1, through=Test1.tests2.through, blank=True) }}} " 2012-06-06T19:49:55+01:00 anonymous andrew 580 Converting from abstract class inheritance to multi-table inheritance commands The Future enhancement 2010-09-14T14:54:55+01:00 It would be great if it were possible to convert an abstract base class to a concrete class with its own table (Removing abstract = True from a base class). 2010-09-14T17:19:47+01:00 karimn2.0@… andrew 932 Support for insert+select databaseapi The Future enhancement 2011-10-14T20:18:18+01:00 "There should be a function/abstraction for doing large scale data migrations that can be implemented as 'insert into ... select ...' Currently doing this with ORM layer is inadvisable as this constructs many objects, runs out of memory quickly and takes forever to run. In comparison the corresponding insert+select query completes in a few seconds." 2011-10-14T21:29:46+01:00 zygmunt.krynicki@… andrew 930 define Command.args for schemamigration documentation 1.0 enhancement 2011-10-02T19:16:28+01:00 "Currently, ""./manage.py help schemamigration"" shows a generic usage string: {{{ Usage: manage.py schemamigration [options] }}} It would be really great for this to look closer to the usage string shown when if you enter ""./manage.py schemamigration"": {{{ Usage: ./manage.py schemamigration appname migrationname [--empty] [--initial] [--auto] [--add-model ModelName] [--add-field ModelName.field_name] [--stdout] }}} At a minimum setting Command.args = """" would help newbies realize that you can actually pass a custom migration name. (This is not mentioned in the introductory documentation, and the output of ""./migrate.py help schemamigration"" does not mention args at all.) " 2011-10-03T13:38:34+01:00 eric@… andrew 956 Fixtures from migrations - add warning documentation 1.0 enhancement 2011-11-17T03:36:51Z "Hi, The recommended way to load fixtures is to call_command(""loaddata"", ""my_fixture.json"") described in the docs: http://south.aeracode.org/docs/fixtures.html#fixtures-from-migrations The only problem is that loaddata will not throw exceptions on any error that might occur while loading the data (ex. invalid json, referential integrity errors etc.) It will print out the stack trace to sys.err and return without throwing an exception. South has no way of knowing that there were any errors and will think that the migration applied cleanly and will mark it so. I don't think there is much you can do without changing Django, but I think it would be nice to at least add a warning to the docs so people are aware of the problem and can deal with it. (We have a Django fork so patched loaddata to throw exceptions if an extra option is passed in. Our call_command became: call_command(""loaddata"", ""my_fixture.json"", exceptiononerror = True) ) Thanks" 2012-03-14T16:48:32Z szabtam@… andrew 1140 Additional error handling for 'app' argument commands The Future enhancement 2012-07-23T17:38:10+01:00 "When specifying the app argument while creating a schemamigration, I spent a bit of time futzing because I had a '/' at the end of the argument which gave me an ambiguous error message. It would have been nice if there was something like: if and app[-1] == '/': raise Exception(""You must specify the app name, not it\'s location. Try removing '\\' from the app )name.\n"" in place to catch this. Thanks for having a form to create tickets for suggestions." 2012-07-24T16:06:40+01:00 anonymous