__group__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter Active Tickets,582,alter_column error in postgres when changing from a textfield,migrations,0.7.1,,defect,andrew,new,2010-09-16T16:13:01+01:00,2010-09-17T12:49:39+01:00,"Altering from a textfield to a boolean in postgres: #db.alter_column('table_name', 'column_name', self.gf('django.db.models.fields.BooleanField')(blank=True)) Comes up with the error: django.db.utils.DatabaseError: column ""column_name"" cannot be cast to type ""pg_catalog.bool"" Same thing happens when changing a textfield to an integer too. Had to use: db.delete_column('table_name', 'column_name') db.add_column('table_name', 'column_name', self.gf('django.db.models.fields.BooleanField')(default=False, blank=True)) instead which worked. ",mark.baker@… Active Tickets,732,Patch for signals.rst...,documentation,unknown,,defect,andrew,new,2011-03-10T12:52:11Z,2011-03-10T12:52:11Z,"Simple patch (actually, an hg bundle) to fix the title under line in signals.rst.",john@… Active Tickets,775,delete_foreign_key doesn't work on sqlite3,databaseapi,0.7.3,,defect,andrew,new,2011-05-20T14:42:40+01:00,2013-02-19T10:54:13Z,"{{{ django.db.utils.DatabaseError: no such table: information_schema.key_column_usage }}} For now, to have the same migration for PostgreSQL and SQLite I'm using {{{ if db.backend_name != 'sqlite3': }}} as a workaround. It's not really a useful operation in SQLite anyway because foreign key constraints are disabled by default. SQLite version: 3.7.6.1",victor.van.den.elzen@… Active Tickets,805,Failure in post_syncdb signal handlers mask failure in migration,migrations,0.7.3,,defect,andrew,new,2011-07-21T23:52:11+01:00,2011-07-22T10:05:58+01:00,"So in migration.migrators.Forwards.migrate_many() is this code: finally: # Call any pending post_syncdb signals south.db.db.send_pending_create_signals(verbosity=self.verbosity, interactive=self.interactive) I'm a little unclear why this is in a finally block and not just the last call in the try block. If an exception is raised, doesn't that mean that the migration failed and the transaction was rolled-back? If so, why send the post_syncdb signals? In my case, what is happening is that I have to go mucking around with the debugger to figure out why my migration is failing because the exception I am causing is ""lost"" when the syncdb handler raises its own exception. So why is this in a finally block, anyway? Boring details: The specifics for my case involve a new model created, data copied from another model to it, then the old model is destroyed. I made an error in the data migration bit, so it raises, but because the transaction is rolled back, the signal goes out, it attempts to remove entries from django_content_type that I'm referring to in another model that is also supposed to be deleted by this migration.",dpisoni@… Active Tickets,806,Removing column with index results in broken migrations,commands,0.7.3,,defect,andrew,new,2011-07-22T07:27:58+01:00,2011-07-22T07:27:58+01:00,"Let's say you rename a column that was previous a `ForeignKey` to a `CharField`. When this migration is applied, there will be a failure, because the directive to remove the index occurs after the column is removed. In SQLite, this throws an error. Same goes for the backwards migration. The column for the foreign key (foo_id) does not exist, but the first thing the backwards migration will attempt to do is create an index on this (nonexistent) column. By simply reversing the order of these directives, the issue is fixed, at least for SQLite. For example: Forwards: delete index, THEN delete column Backwards: create column, THEN create index",Dan Loewenherz Active Tickets,919,sqlite columns re-ordered unexpectedly after delete/update column,commands,0.7,,defect,andrew,infoneeded,2011-09-06T11:26:26+01:00,2011-09-08T05:06:39+01:00,"I have a simple migration: {{{ class Migration: def forwards(self, orm): # Deleting field 'SoftwareItem.app_name' db.delete_column('reviewsapp_softwareitem', 'app_name') def backwards(self, orm): # Adding field 'SoftwareItem.app_name' db.add_column('reviewsapp_softwareitem', 'app_name', orm['reviewsapp.softwareitem:app_name']) }}} With 0.6 everything worked fine, but with 0.7, the columns are being re-ordered (as can be seen by putting a pdb in the migration and inspecting the schema before and after the call): Before 0008_remove_softwareitem_app_name: sqlite> .schema reviewsapp_softwareitem CREATE TABLE ""reviewsapp_softwareitem"" ( ""id"" integer NOT NULL PRIMARY KEY, ""package_name"" varchar(100) NOT NULL, ""app_name"" varchar(100) NOT NULL, ""ratings_total"" integer NOT NULL DEFAULT 0, ""ratings_average"" decimal NOT NULL DEFAULT 0, ""date_ratings_updated"" datetime NOT NULL DEFAULT '2010-12-09 20:47:18.200195'); After 0008_remove_softwareitem_app_name: sqlite> .schema reviewsapp_softwareitem CREATE TABLE ""reviewsapp_softwareitem"" ( ""ratings_total"" integer, ""ratings_average"" decimal, ""id"" integer PRIMARY KEY, ""package_name"" varchar(100), ""date_ratings_updated"" datetime); ",absoludity+south@… Active Tickets,925,"Irregular use of the ""default"" keyword in the API",databaseapi,0.7.3,,defect,andrew,new,2011-09-20T23:51:58+01:00,2012-06-22T00:33:20+01:00,"In '''south.creator.freezer''', '''default''' is marked as an useless DB keyword. {{{ USELESS_DB_KEYWORDS = [""related_name"", ""default"", ""blank""] }}} Yet South exhibits an inconsistent behaviour. The keyword appears in the '''db.add_column''' action, but not on '''db.alter_column'''. The '''DEFAULT''' database constraint created by South for a given field ends up being removed in a subsequent schema migration for that same field. I created a test project with Django 1.3 and South 0.7.3, then a sample application, named '''app''', with the model below. {{{ class MyModel(models.Model): some_field = models.CharField(max_length=1, default='a') }}} I then made an initial migration with `django-admin.py schemamigration --initial app` and ran it (`django-admin.py migrate`). South created the following table schema. {{{ CREATE TABLE ""app_mymodel"" ( ""id"" integer NOT NULL PRIMARY KEY, ""some_field"" varchar(1) NOT NULL DEFAULT 'a' ); }}} Afterwards, I changed the definition of '''!MyModel.some_field'''. The field is now two characters wide. {{{ class MyModel(models.Model): some_field = models.CharField(max_length=2, default='a') }}} Created another migration and ran it (`django-admin.py schemamigration app --auto a; django-admin.py migrate`). South updated the table schema as follows. {{{ CREATE TABLE ""app_mymodel"" ( ""id"" integer PRIMARY KEY, ""some_field"" varchar(2) NOT NULL ); }}} Notice that the '''DEFAULT''' part of the '''CREATE TABLE''' clause above was dropped. I've experimented with both SQLite 3.6 and PostgreSQL 8.4, to the same results. I think South API should either use default values for the database schema, and sustain it throughout migrations, or not use it at all. Using it on some commands, and disregarding it on others, does not seem to be a good idea.",rviotti@… Active Tickets,949,Oracle: not raising exceptions from DatabaseOperations.execute breaks Oracle backend,migrations,mercurial,,defect,andrew,new,2011-11-11T23:44:54Z,2011-11-11T23:44:54Z,"The Oracle backend's DatabaseOperations.alter_column depends on catching and checking exceptions thrown by DatabaseOperations.execute, but changeset 0918d7a8e8395370529e9ace222e6f546d860d3f breaks this by printing the error and not re-raising. Could these kinds of errors maybe be caught at a higher level, that is, print and exit only if the backend doesn't handle it? Maybe in Migrator.run_migration?",Sam Hartsfield Active Tickets,982,Changing fields to null=True fails on MySql InnoDB,commands,unknown,,defect,andrew,assigned,2012-01-06T12:29:44Z,2012-06-01T21:56:02+01:00,"Hi, I've noticed that changing fields to null=True and then running the automatic south migrations fails on InnoDB. {{{ ... File ""/Users/xxx/Sites/online_virtualenv/lib/python2.7/site-packages/MySQLdb/cursors.py"", line 174, in execute self.errorhandler(self, exc, value) File ""/Users/xxx/Sites/online_virtualenv/lib/python2.7/site-packages/MySQLdb/connections.py"", line 36, in defaulterrorhandler raise errorclass, errorvalue _mysql_exceptions.OperationalError: (1005, ""Can't create table 'demo.#sql-1b9_2e' (errno: 121)"") }}} This inconsistently (unfortunately) happens on various Ubuntu & MacOS setups. !MacOs Ver. 14.14 Distrib 5.5.14 failed for me today. Funny thing is, that even though this error is raised, the mentioned field is actually made nullable in the DB. So commenting out the offending line in the migration and rerunning it fixes it. InnoDB error log doesn't show much interesting info. {{{ 120106 13:05:56 [Warning] Invalid (old?) table or database name '#sql-1b9_2e' }}} ciao, Klaas",klaas@… Active Tickets,1025,dbs.create_table does not create anything,commands,unknown,,defect,andrew,infoneeded,2012-02-06T11:24:13Z,2012-02-06T12:13:43Z,"As reported at [http://groups.google.com/group/south-users/browse_thread/thread/953ff52b89c5993a], the dbs['mydb'].create_table method seems not to work. The db.create_table method works instead. Is the create_table method works only in databases wich have inside them the south_migrationhistory table? If so, ho to add it to non-default databases?",candini@… Active Tickets,1028,db.send_create_signal documentation mentions startmigration,documentation,unknown,,defect,andrew,new,2012-02-07T22:29:53Z,2012-02-07T22:29:53Z,"the documentation for db.send_create_signal mentions that ""startmigration will add this automatically for you."" I think startmigration has been replaced by ""schemamigration --initial""",anonymous Active Tickets,1067,missing _ormbase in case of complex inheritance pattern,migrations,unknown,,defect,andrew,new,2012-04-19T12:01:16+01:00,2012-04-19T12:01:16+01:00,"Lets have the following inheritance structure: (Using south 0.7.4 and Django 1.3.1) {{{ class Base(model.Model): f1 = IntegerField() class OtherBase(Base): f2 = IntegerField() class Meta: abstract = True class M1(OtherBase): f3 = IntegerField() }}} Django handles this situation well, the M1 have f1, f2, f3 attributes. However if I create datamigration the orm.M1 wont have f1 attribute only f2, f3. I guess the main reason is that the Migration.models looks like the following: {{{ models = { 'test.M1': { 'Meta': {'object_name': 'M1'}, [...] }}} However it should look like this: {{{ models = { 'test.M1': { 'Meta': {'object_name': 'M1', '_ormbases': ['test.Base']}, [...] }}}",szferi@… Active Tickets,1119,cant change foreginkey from null=false to null=true in postgresql,commands,unknown,,defect,andrew,new,2012-06-14T20:10:57+01:00,2012-06-14T20:10:57+01:00,"I'm using South 0.7.5 and PostgreSQL 9.0.4 on x86_64-apple-darwin11.1.0, compiled by GCC i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00), 64-bit. I am starting with a new database, and migrations which may have been created by prior versions of South (0.7.3???). I get an error when trying to The tail end of the stack trace is the following: File ""/Users/chema/envs/cf/lib/python2.7/site-packages/south/db/generic.py"", line 533, in alter_column field.rel.to._meta.get_field(field.rel.field_name).column File ""/Users/chema/envs/cf/lib/python2.7/site-packages/south/db/generic.py"", line 273, in execute cursor.execute(sql, params) File ""/Users/chema/envs/cf/lib/python2.7/site-packages/django/db/backends/util.py"", line 34, in execute return self.cursor.execute(sql, params) File ""/Users/chema/envs/cf/lib/python2.7/site-packages/django/db/backends/postgresql_psycopg2/base.py"", line 44, in execute return self.cursor.execute(query, args) django.db.utils.DatabaseError: constraint ""revoked_by_id_refs_id_4128367e0dc3da83"" for relation ""credits_transaction"" already exists I managed to fix this by changing south/db/generic.py to include the following: # Drop all foreign key constraints try: self.delete_foreign_key(table_name, name) except ValueError: # There weren't any ignore_constraints=True #THIS IS THE LINE I ADDED pass",anonymous Active Tickets,1165,DatabaseOperations._find_foreign_constraints wont work with default arguments,databaseapi,0.7.6,,defect,andrew,infoneeded,2012-09-04T19:49:17+01:00,2012-09-04T19:54:56+01:00,"The default value for the column_name parameter is None, if _find_foreign_constraints is called with this the first line calls _contraints_affecting_columns passing the None parameter inside of a list. Inside _contraints_affecting_columns there is a check to see if columns is None, which as far as I can tell, it can't be. This causes an exception.",reames@… Active Tickets,1168,db_column and bytestrings/unicode-equivalence,commands,unknown,,defect,andrew,assigned,2012-09-13T15:29:10+01:00,2012-09-21T13:33:51+01:00,"i had a field-definition like: thing = IntegerField(db_colum='that') later i changed it to: thing = IntegerField(db_column=u'that') nothing really changed with this, but since then, everytime i am trying to use schemamigration--auto when adding a field for example, south thinks that there was a change with the ""thing"" field, because, the db_column value changed. but it should be the same... 'that' equals u'that'. so now i am not sure how to fix this. for now i see 2 solutions/workarounds: 1. remove the ""u"" 2. change the previous migration, and change all the db_column values to unicode-values in that migration's ""models"" section. is there a way to handle this problem? p.s: technically, i did not change the db_column, i started using {{{from __future__ import unicode_literals}}}. but the effect is the same...",anonymous Active Tickets,1178,Schema migration doesn't respect models.Field 'db_column' attribute,migrations,0.7.6,,defect,andrew,reopened,2012-09-27T10:16:53+01:00,2012-09-27T23:10:01+01:00," 1. added a model with: {{{#!python class ValeurCritere(models.Model): annonce = models.ForeignKey(Annonce, related_name=""_valeurs_criteres"") critere = models.ForeignKey(Critere, related_name=""_valeurs_criteres"") text_val = models.TextField( u""Valeur Texte"", blank=True, null=True, ) }}} 2. created a schemamigration for it and applied the migration 3. then changed the model to: {{{#!python class ValeurCritere(models.Model): annonce = models.ForeignKey(Annonce, related_name=""_valeurs_criteres"") critere = models.ForeignKey(Critere, related_name=""_valeurs_criteres"") _text_val = models.TextField( u""Valeur Texte"", db_column=""text_val"", blank=True, null=True, ) }}} kept on working on my code, everything's ok, all tests on green, then created a new model in the same app and 5. created a new schemamigration, hopefully I looked at it before applying it, because here's what I found in it: {{{#!python def forwards(self, orm): # ... # Deleting field 'ValeurCritere.text_val' db.delete_column('core_valeurcritere', 'text_val') # Adding field 'ValeurCritere._text_val' db.add_column('core_valeurcritere', '_text_val', self.gf('django.db.models.fields.TextField')(null=True, db_column='text_val', blank=True), keep_default=False) }}} The source of the problem is in creator.changes.AutoChanges.get_changes, lines 185 to 217 which only check the model fields names where it should also look for the db_column attributes. I had a quick try at a patch but it would be too involved to make sure it won't break something else and I can't afford to spend enough time on this by now, since I don't have any production data yet for this model it won't break anything for me. ",bruno.desthuilliers@… Active Tickets,1179,Validation after convert_to_south fails on custom user models,commands,0.7.6,,defect,andrew,new,2012-10-02T08:30:25+01:00,2013-05-01T06:00:51+01:00,"The convert_to_south management command appears to invoke validation at some point after creating the initial migration for a project. If you are using Django 1.5, and are using a custom AUTH_USER_MODEL, this validation fails, with an error message something like: {{{ CommandError: One or more models did not validate: auth.user: Model has been swapped out for 'accounts.User' which has not been installed or is abstract. }}} To reproduce: Create a fresh project with a custom auth app; create a custom user model in that app; and try to initialize South on that app.",russell@… Active Tickets,1186,"mysql _lookup_constraint_references can return None, expected to return iterable.",migrations,mercurial,,defect,andrew,new,2012-11-07T21:04:49Z,2013-04-22T12:15:48+01:00,"During column renaming, _lookup_contraint_references is called and the return value is directly assigned to a tuple. [1] Unfortunately, _lookup_constraint_references sometimes returns None. [2] I suppose this is probably ""never supposed to happen"" but I've run into it multiple times when working with renaming columns in m2m through tables. [1] https://bitbucket.org/andrewgodwin/south/src/463114da627da10946aa0ae42a8b5745f302633a/south/db/mysql.py?at=default#cl-41 [2] https://bitbucket.org/andrewgodwin/south/src/463114da627da10946aa0ae42a8b5745f302633a/south/db/mysql.py?at=default#cl-234",stephen@… Active Tickets,1190,Multiple databases: TestCase init fails,commands,0.7.6,,defect,andrew,new,2012-11-26T15:37:48Z,2012-11-26T15:37:48Z,"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. https://github.com/qris/south-migration-multiple-databases-problem It may depend on the design of your router: if I re-enable the line in SchoolDatabaseRouter that allows MigrationHistory to sync to all databases, the problem disappears. It will probably also appear only if you have a non-default database with no TEST_MIRROR configured. Details below copied from the link above to help people find it here. 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 ",Chrisl Wilson Active Tickets,1191,Firebird: Incorrect generation of DEFAULT and CHECK tokens in CREATE TABLE statement,migrations,0.7.6,,defect,andrew,new,2012-12-04T02:39:45Z,2012-12-19T08:29:42Z,"Trying ./manage.py migrate... I'm seeing DatabaseError: (-104, 'isc_dsql_prepare: \n Dynamic SQL Error\n SQL error code = -104\n Token unknown - line 1, column 195\n DEFAULT -- CREATE TABLE ""CATALOGUE_PRODUCTRECOMMENDATION"" (""ID"" integer NOT NULL PRIMARY KEY, ""PRIMARY_ID"" integer NOT NULL, ""RECOMMENDATION_ID"" integer NOT NULL, ""RANKING"" smallint CHECK (""RANKING"" >= 0) DEFAULT 0 NOT NULL);') Instead of valid for FB: ""DEFAULT 0 CHECK (""RANKING"" >= 0)"". Using UNICODE_FSS, database dialect 3, firebird-superserver 2.1. Using Django 1.4.2, south 0.7.6, python 2.6 on Debian Squeeze. With best regards. ",avs Active Tickets,1192,migration fails for sqlite if TextField default value contains a percentage sign,migrations,0.7.6,,defect,andrew,new,2012-12-06T19:50:43Z,2012-12-06T19:50:43Z,"Using South 0.7.6 / Python 2.7.3 / Django 1.4.2, I created a model field like: email_body = models.TextField(default=""Please download your free report: %LINK%"") another_field = models.BooleanField(default=False) A schemamigration --auto successfully created a migration, and did end up creating an email_body column, but will fail trying to create the next ""another_field"" migration, whatever it may be. {{{ Traceback (most recent call last): File ""./manage.py"", line 10, in execute_from_command_line(sys.argv) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/core/management/__init__.py"", line 443, in execute_from_command_line utility.execute() File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/core/management/__init__.py"", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/core/management/base.py"", line 196, in run_from_argv self.execute(*args, **options.__dict__) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/core/management/base.py"", line 232, in execute output = self.handle(*args, **options) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/management/commands/migrate.py"", line 108, in handle ignore_ghosts = ignore_ghosts, File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/__init__.py"", line 213, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 235, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 310, in migrate_many result = self.migrate(migration, database) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 133, in migrate result = self.run(migration) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 107, in run return self.run_migration(migration) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/Users/michaelrooney/Code/nyr/website/nyr/migrations/0005_auto__add_field_developmenttranslation_email_subject__add_field_develo.py"", line 14, in forwards keep_default=False) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/db/sqlite3.py"", line 31, in add_column field.column: self._column_sql_for_create(table_name, name, field, False), File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/db/generic.py"", line 44, in _cache_clear return func(self, table, *args, **opts) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/db/sqlite3.py"", line 103, in _remake_table "", "".join([""%s %s"" % (self.quote_name(cname), ctype) for cname, ctype in definitions.items()]), File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/south/db/generic.py"", line 273, in execute cursor.execute(sql, params) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/db/backends/util.py"", line 44, in execute sql = self.db.ops.last_executed_query(self.cursor, sql, params) File ""/Users/michaelrooney/Code/nyr/env/lib/python2.7/site-packages/django/db/backends/__init__.py"", line 603, in last_executed_query return smart_unicode(sql) % u_params TypeError: not enough arguments for format string }}}",mrooney.south@… Active Tickets,1216,"MySQL backend reliant on ""NAME"" database property, which might not be present.",databaseapi,0.7.6,,defect,andrew,new,2013-02-15T20:12:10Z,2013-02-15T20:12:10Z,"Currently a number of functions rely on getting the django ""NAME"" key in the DATABASES dictionary. Examples of such functions are _lookup_reverse_constraint, _lookup_constraint_references). That property is not required for mysql; you can have the user have a default DB or have the ""db"" parameter specified in the ""OPTIONS"" key. One example of what this breaks is the db.delete_foreign_key, which generates a query for metadata where schema_name = """".",antonio@… Active Tickets,1220,Import of django DatabaseError from wrong location,commands,unknown,,defect,andrew,new,2013-02-25T16:51:50Z,2013-02-25T16:51:50Z,"In 0.7.6 (or latest trunk) in conjunction with a django version before multi database support. The following error occurs if you run the migrate or any management command. {{{ There is no South database module 'south.db.mysql' for your database. Please either choose a supported database, check for SOUTH_DATABASE_ADAPTER[S] settings, or remove South from INSTALLED_APPS. }}} The reason for this is an ImportError in south.db.__init__ when it tries to import the corresponding south db backend, but the ImportError is not triggered by a missing database module but because django.db.utils doesn't exists. {{{ Traceback (most recent call last): File ""/home/jackson/1my/dev/placement/redesign/placement24/south/db/__init__.py"", line 68, in module = __import__(module_name, {}, {}, ['']) File ""/home/jackson/1my/dev/placement/redesign/placement24/south/db/mysql.py"", line 5, in from south.db import generic File ""/home/jackson/1my/dev/placement/redesign/placement24/south/db/generic.py"", line 6, in from django.db.utils import DatabaseError ImportError: No module named utils }}} I have attached a patch agains 0.7.6 (should also apply against trunk) that imports the DatabaseError from django.db instead.",w.spee@… Active Tickets,1222,"Index naming seems to have changed in Django 1.5, causes db.delete_index to fail",migrations,0.7.6,,defect,andrew,new,2013-02-27T11:11:50Z,2013-03-13T09:56:21Z,"I just upgraded to Django 1.5 and wanted to use the new index_together feature. I deleted some db_index=True parameters and added the new Meta-option, then created the migration and (since it is not yet supported) added the index(_together) creation by hand. (I don't think the last part matters) What happened now is that when migrating South tried to remove the old indexes (which is correct), but used a wrong name for them: {{{ DatabaseError: (1091, ""Can't DROP 'project_trade_81aefa79'; check that column/key exists"") }}} When going back to Django 1.4.4 this same migration works like a charm. The suggested manual fixes of South clearly show the different names: {{{ CREATE INDEX `project_tradedatadumps_3b1c9c31` ON `project_tradedatadumps` (`created_at`); CREATE INDEX `project_trade_4d0541be` ON `project_trade` (`position`); CREATE INDEX `project_trade_53af33f8` ON `project_trade` (`trade_state`); CREATE INDEX `project_trade_55e41dff` ON `project_trade` (`formation`); CREATE INDEX `project_trade_71e223e3` ON `project_trade` (`expires_at`); CREATE INDEX `project_tradedatadumps_fde81f11` ON `project_tradedatadumps` (`created_at`); CREATE INDEX `project_trade_4757fe07` ON `project_trade` (`position`); CREATE INDEX `project_trade_8072a9de` ON `project_trade` (`trade_state`); CREATE INDEX `project_trade_f1a41f23` ON `project_trade` (`formation`); CREATE INDEX `project_trade_81aefa79` ON `project_trade` (`expires_at`); }}} After checking out how these names are generated (south/db/generic.py create_index_name) I noticed South is using the _digest function of BaseDatabaseCreation - that one saw some changes for Python 3.3: https://github.com/django/django/blame/1.5/django/db/backends/creation.py#L27 https://github.com/django/django/commit/e4ea53677449cfc56a0093bfbd92cb482020bb1e ""Ensued that SQL indexes are alwasy created in the same name. Previous this used Python's builtin hash() function, which has never been guarnteed to be stable across implementations (CPython/Jython/etc.) or 32/64 bitness. However, this in practice it was stable. However, with the impending release of Python 3.3 hash randomizations is enabled by default, which would mean the index name changed between program invocations."" It ''looks'' like this is completely breaking all django-south applications that created indexes before Django 1.5 and try do remove them after upgrading to 1.5 I'll try to create a testcase project on GitHub tomorrow, but I can't guarantee I'll find the time to do it.",strayer@… Active Tickets,1227,Fix deprecated @@storage_engine usage which halts MySQL migration,commands,0.7.6,,defect,andrew,new,2013-03-13T13:47:59Z,2013-03-13T13:47:59Z,"_mysql_exceptions.Warning: '@@storage_engine' is deprecated and will be removed in a future release. Please use '@@default_storage_engine' instead South-0.7.6-py2.6.egg/south/db/mysql.py"", line 179, in connection_init cursor.execute(""SET storage_engine=%s;"" % self._get_setting('STORAGE_ENGINE')) MySQL version is 5.6.10. The line should be: cursor.execute(""SET default_storage_engine=%s;"" % self._get_setting('STORAGE_ENGINE'))",jzempel@… Active Tickets,1228,UnknownMigration can't be converted to string,migrations,unknown,,defect,andrew,new,2013-03-13T21:03:42Z,2013-03-13T21:03:42Z,"''_str_'' method of ''!UnknownMigration'' and it's base ''!BrokenMigration'' expects that ""traceback"" attribute exists, but sometimes it's not. This happens when ''!UnknownMigration'' is raised in ''_guess_migration'' method of ''migration.base.Migrations'': {{{ # line 203 of migration/base.py raise exceptions.UnknownMigration(prefix, None) }}} This results in !KeyError: 'traceback' when trying to migrate to non-existent migration ",someuniquename@… Active Tickets,1230,MySQL CREATE TABLE and storage engine,migrations,0.7.6,,defect,andrew,new,2013-03-15T12:51:33Z,2013-03-15T16:09:33Z,"When a storage engine is specified for MySQL, the storage engine should be specified in the CREATE TABLE statement instead of (or in addition to) setting the session storage_engine variable. http://dev.mysql.com/doc/refman/5.5/en/create-table.html e.g. SET storage_engine=InnoDB CREATE TABLE `name` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `item` varchar(16) NOT NULL) ENGINE=InnoDB",Kris Kumler Active Tickets,1235,changing from NullBoolean to Boolean field causes error,migrations,0.7.6,,defect,andrew,new,2013-03-27T02:00:40Z,2013-03-27T02:02:06Z,"Previous model had models.NullBooleanField. Changed to models.BooleanField. This is similar to going from models.BooleanField(null=True) to models.BooleanField(null=False) from a database standpoint. Applying this migration causes an error if any of the rows actually have the field set to NULL (field cannot be NULL). Perhaps it should trigger the prompt for a default value or something similar. I went in to python and ran [code] for node in Node.objects.all(): if node.field == None: node.field == False node.save() [/code] and the migration worked without errors. Database was sqlite 3.7.16.",mark.wolf.music@… Active Tickets,1242,hstore add_column default must be '' not {},migrations,0.7.5,,defect,andrew,new,2013-04-12T00:37:21+01:00,2013-04-15T02:18:51+01:00,"after a schemamigration --auto, the migration script contains an add_column for a hstore field with default={} : db.add_column('data_item', 'kv', self.gf('djorm_hstore.fields.DictionaryField')(default={}, db_index=True), keep_default=False) This default value throw the following Exception django.db.utils.DatabaseError: Unexpected end of string. When you replace it by default='', it works as expected. You can also put the default in your app/models.py.",Stéphane Kanschine Active Tickets,1244,no such table: auth_permission on initial syncdb,commands,0.7.6,,defect,andrew,new,2013-04-12T20:04:30+01:00,2013-04-12T20:13:43+01:00,"{{{ $ ./manage.py syncdb Traceback (most recent call last): File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/base.py"", line 222, in run_from_argv self.execute(*args, **options.__dict__) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/base.py"", line 255, in execute output = self.handle(*args, **options) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/base.py"", line 385, in handle return self.handle_noargs(**options) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/south/management/commands/syncdb.py"", line 90, in handle_noargs syncdb.Command().execute(**options) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/base.py"", line 255, in execute output = self.handle(*args, **options) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/base.py"", line 385, in handle return self.handle_noargs(**options) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/commands/syncdb.py"", line 109, in handle_noargs emit_post_sync_signal(created_models, verbosity, interactive, db) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/core/management/sql.py"", line 195, in emit_post_sync_signal interactive=interactive, db=db) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/dispatch/dispatcher.py"", line 170, in send response = receiver(signal=self, sender=sender, **named) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py"", line 88, in create_permissions ""content_type"", ""codename"" File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/query.py"", line 123, in _result_iter self._fill_cache() File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/query.py"", line 939, in _fill_cache self._result_cache.append(next(self._iter)) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/query.py"", line 344, in _safe_iterator for item in iterator: File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/query.py"", line 1141, in iterator for row in self.query.get_compiler(self.db).results_iter(): File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/sql/compiler.py"", line 775, in results_iter for rows in self.execute_sql(MULTI): File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/models/sql/compiler.py"", line 840, in execute_sql cursor.execute(sql, params) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/backends/util.py"", line 41, in execute return self.cursor.execute(sql, params) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py"", line 366, in execute six.reraise(utils.DatabaseError, utils.DatabaseError(*tuple(e.args)), sys.exc_info()[2]) File ""/jonas/dev/mfd/env/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py"", line 362, in execute return Database.Cursor.execute(self, query, params) DatabaseError: no such table: auth_permission Syncing... Creating tables ... }}} * Python 2.7 * No initial fixtures * No custom permissions * Django's `syncdb` works fine. I'm happy to help debug this. I can't make the code public but I can send it to a few Selected Individuals (tm).",jonas@… Active Tickets,1246,South does not detect added columns if they start with 'is_',commands,unknown,,defect,andrew,new,2013-04-17T07:51:00+01:00,2013-04-17T08:02:37+01:00,South does not detect added columns if they start with 'is_',me@… Active Tickets,1247,"Supress ""fatal"" database errors when not actually fatal",commands,unknown,,defect,andrew,new,2013-04-20T19:02:19+01:00,2013-04-20T19:02:19+01:00,"This is a follow-up to #1120. When renaming a child table, south tries to rename any id sequences, however if those sequences do not exist, a ""FATAL ERROR"" from the db is printed to output. This can be very confusing, especially during testing, resulting in lost time trying to hunt down the source of the issue.",bendavis78@… Active Tickets,1251,Renaming a table doesn't rename foreign key indexes,databaseapi,0.7.6,,defect,andrew,new,2013-05-03T05:29:39+01:00,2013-05-03T16:33:51+01:00,"I'm refactoring a model fairly significantly, so I'm trying to do it piece by piece, by creating a new model and then migrating the fields that I need with a data migration. When I rename a table from tasks_task to tasks_taskold: {{{ def forwards(self, orm): db.rename_table('tasks_task', 'tasks_taskold') }}} This is the state of the tasks_task table after the rename: {{{ Table ""public.tasks_taskold"" Column | Type | Modifiers -------------+--------------------------+------------------------------------------------------------ id | integer | not null default nextval('tasks_taskold_id_seq'::regclass) name | character varying(256) | not null project_id | integer | not null status_id | integer | not null estimate | numeric(4,2) | assigned_id | integer | not null description | text | not null reporter_id | integer | not null priority_id | integer | not null reported | timestamp with time zone | not null modified | timestamp with time zone | not null Indexes: ""tasks_taskold_pkey"" PRIMARY KEY, btree (id) ""tasks_task_assigned_id"" btree (assigned_id) ""tasks_task_priority_id"" btree (priority_id) ""tasks_task_project_id"" btree (project_id) ""tasks_task_reporter_id"" btree (reporter_id) ""tasks_task_status_id"" btree (status_id) Foreign-key constraints: ""assigned_id_refs_id_75189049953a9b18"" FOREIGN KEY (assigned_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED ""priority_id_refs_id_4aa58681e4eb47ae"" FOREIGN KEY (priority_id) REFERENCES tasks_priority(id) DEFERRABLE INITIALLY DEFERRED ""project_id_refs_id_314823387b63f6b0"" FOREIGN KEY (project_id) REFERENCES tasks_project(id) DEFERRABLE INITIALLY DEFERRED ""reporter_id_refs_id_75189049953a9b18"" FOREIGN KEY (reporter_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED ""status_id_refs_id_5527e3909e88f322"" FOREIGN KEY (status_id) REFERENCES tasks_status(id) DEFERRABLE INITIALLY DEFERRED Referenced by: TABLE ""tasks_action"" CONSTRAINT ""task_id_refs_id_464450d0c534db68"" FOREIGN KEY (task_id) REFERENCES tasks_taskold(id) DEFERRABLE INITIALLY DEFERRED }}} It still has foreign key references to tasks_task_*, so trying to create the new Tasks model fails: {{{ $ ./manage.py migrate tasks Running migrations for tasks: - Migrating forwards to 0008_add_newstyle_task. > tasks:0007_rename_task > tasks:0008_add_newstyle_task FATAL ERROR - The following SQL query failed: CREATE INDEX ""tasks_task_reporter_id"" ON ""tasks_task"" (""reporter_id""); The error was: relation ""tasks_task_reporter_id"" already exists Error in migration: tasks:0008_add_newstyle_task DatabaseError: relation ""tasks_task_reporter_id"" already exists }}} Shouldn't South be renaming the foreign key fields too? (eg. tasks_task_priority_id -> tasks_taskold_priority_id) (There doesn't seem to be a rename_index command either, otherwise I could add those after the rename_table command - unless db.delete_index is what I should be using? It's not clear from the documentation)",Anthony Briggs Active Tickets,1253,Using my.cnf for db configuration causes migrations to fail,migrations,0.7.6,,defect,andrew,new,2013-05-13T20:44:29+01:00,2013-05-13T20:44:29+01:00,"It is possible to configure the MySQL backend using /etc/my.cnf (or some other config file). The configuration looks something like: {{{ DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'OPTIONS': { 'read_default_file': '/etc/my.cnf', 'read_default_group': 'django', }, }, } }}} In this case, /etc/my.cnf might look like: {{{ [client] host=localhost port=3306 user=my_user password=an_insecure_password [mysql] database=django [django] database=django user=django password=yet_another_password }}} Note that the database NAME, USER, and PASSWORD are all taken from my.cnf. Unfortunately, this will cause migrations to fail because South uses the NAME configuration for multiple lookup purposes (see, for instance, _lookup_constraint_references() in mysql.db, around line 228). These lookups fail when NAME isn't set. The workaround is simply to add the NAME setting. However, for those of us who use my.cnf to manage our databases, that isn't ideal. We may use the same source installation to deploy to different databases, letting my.cnf control everything. A more ideal solution would be to get the database name from the database itself. However, at the very least, it should be documented that settings.DATABASES[db_alias]!['NAME'] is a required setting. ",travis.jensen@… Active Tickets,1255,pytz for Google Appengine breaks South,migrations,unknown,,defect,andrew,new,2013-05-15T12:05:19+01:00,2013-05-15T12:05:19+01:00,"To reproduce: enable timezones in django (USE_TZ = True). Create a model with a datetime field, with a default value which is either a literal, or defaults to a literal. e.g. either ""DateTimeField(default=datetime.datetime())"" or ""x = datetime.datetime() ... DateTimeField(default=x)"". Now do a schemamigration, and then a migrate. Install gae pytz into main app folder (can be listed under installed_apps or not, doesn't make any difference). Now run a test: manage.py test . South fails with a different error depending upon whether imports pytz or not. If imports gae pytz, then fails with this error: ""ValueError: Cannot successfully create field for model : No api proxy found for service ""memcache"". Otherwise, fails with this error: ValueError: Cannot successfully create field for model : 'Europe/London'. I managed to make these errors go away by hacking the migrations to make all datetime literals timezone-aware, and the South source code to import timezone, but this is not a solution ... the solution would use the migrations ""in tact"", i.e. without adding timezone information to the datetime literals.",jon@… Active Tickets,1256,"test_alter_unique test fail, 0.7.5&6",databaseapi,0.7.6,,defect,andrew,assigned,2013-05-18T08:01:50+01:00,2013-05-18T12:38:57+01:00,".....................................................FATAL ERROR - The following SQL query failed: INSERT INTO test_alter_unique (spam, eggs) VALUES (1, 42) The error was: column eggs is not unique . line 477 south/tests/db.py def test_alter_unique(self): python -V 2.7.3, 2.6.8",Ian Delaney Active Tickets,1262,South 0.8+: Cannot add CharFields using sqlite,commands,unknown,,defect,andrew,new,2013-05-30T21:33:12+01:00,2013-06-15T16:31:39+01:00,"After revision https://bitbucket.org/andrewgodwin/south/commits/0f7403ce4f398265c7877a7c64071516cd87e6ea , one can no longer add new CharFields with an empty default using South. Steps to reproduce: 1. Find a model already managed by South. 2. Add a CharField, like so: abc = models.CharField(max_length=200) 3. ""python manage.py schemamigration APPNAME --auto"" 4. Answer ""2."" to the defaults question. Provide an empty string as the answer ''. 5. python manage.py migrate You'll see an error about a column that cannot be NULL. Even if you define your field with a default, like so abc = models.CharField(default='', max_length=200) Or even: abc = models.CharField(default='', blank=True, max_length=200) This will no longer work. Of note: if you provide a non-blank default, it'll work. So: abc = models.CharField(default='something', blank=True, max_length=200) This last one will work.",silviogutierrez@… Active Tickets,1265,South: MySQL: drop index fails on models created with --initial due to incorrect hash value,commands,mercurial,,defect,andrew,new,2013-06-04T22:56:05+01:00,2013-06-10T14:46:39+01:00,"What I did: Removed the 'db_index' option from a model, and attempted a migration What I expected to happen: Migration process removes the index (in this case, the index `drop_index_fails_example_30d9b87f`) What Happened: South tried to remove the incorrect index, and therefore failed: DatabaseError: (1091, ""Can't DROP 'drop_index_fails_example_c632933c'; check that column/key exists"") How to reproduce: ./manage.py startapp drop_index_fails ./manage.py schemamigration drop_index_fails --initial ./manage.py migrate drop_index_fails ./manage.py schemamigration drop_index_fails --auto ./manage.py migrate drop_index_fails ",eode@… Active Tickets,1269,Oracle and Django 1.5 with South - character fields missing null=True in migrations.,commands,unknown,,defect,andrew,new,2013-06-17T23:51:13+01:00,2013-06-19T15:28:18+01:00,"Hello, Django 1.5 changed the way it handled the Oracle quirk of empty strings being stored as null. In Django 1.4, the field emitted null=True if Oracle was being used and the field allowed empty strings. This meant that South created migrations correctly for Oracle. A patch [1] in Django 1.5 took that functionality away. Now South creates character fields for Oracle without the null=True which means every time Django tries put an empty string into that field, the database errors. Until this is fixed, South is effectively unusable with Django 1.5. I've patched my local version of South in south.creator.changes.BaseChanges.split_model_def to detect fields with empty_strings_allowed and set null = True, but I haven't done any connection detection as we only use Oracle and I'm not sure of the best way to get connection detection into that module. Anyway, if there is some way I can help fix this, please let me know. We will be using Django 1.5 for Production within a few months and would prefer not to use our own modified South. Thanks, Michael. [1] https://code.djangoproject.com/attachment/ticket/17957/17957.patch ",michael.miller@… Active Tickets,584,Speedup constraint queries,migrations,unknown,,enhancement,andrew,new,2010-09-17T01:12:42+01:00,2010-09-17T01:12:42+01:00,"MySQL has _very_ slow reads from the information_schema table. This fork adds a caching layer to generic.DatabaseOperations. On my production setup with 44 migrations it cuts the number of info_schema queries by 70% and the ones it does do are cheaper. =How It Works= All constraint queries now go through the lookup_constraint() method. If the cache is empty or invalid _fill_constraint_cache() gets called. The cache itself is just a dictionary of cache[db_name][table_name][column_name] with the column value being a set() of constraints for that column. The cache gets invalidated at the table_name level. If the table changes the value of cache[db_name][table_name] is set to INVALID. When a lookup happens if the cache is empty it gets filled. If the cache for that table is INVALID it gets filled. If the cache has been populated and isn't INVALID either the column constraints are returned - or in the usual case - we get a KeyError for the column and return an empty list (most keys don't have constraints). The generic Ops class fills the cache per-table. The MySQL Ops class fills the cache for the whole database at once. That difference is hidden in the _is_valid_cache() method. As a result of the refactoring the mysql module lost net 20 lines of code and the generic module gained net 60.",jackdied@… Active Tickets,1203,Add mysql_oursql to south engine_modules,commands,mercurial,,enhancement,andrew,new,2013-01-22T10:17:38Z,2013-01-22T10:17:38Z,"Hello, I am looking into migrating from MySQLdb to OurSQL on the count that OurSQL seams to allow gevent monkey patching. The database backend can be found here: https://github.com/dcramer/django-oursql but it looks like south throws an exception if I try to use: 'ENGINE': 'mysql_oursql.standard' as a database engine. The error stems from the fact that mysql_oursql is not included in the engine_modules aliases from south.db. The patch bellow adds the oursql django engine to the filters. I have not tested it very much but so far all looks well when using it with my app. {{{ diff -r 6c69cb5f3710 south/db/__init__.py --- a/south/db/__init__.py Fri Jan 04 20:08:20 2013 +0000 +++ b/south/db/__init__.py Tue Jan 22 12:12:32 2013 +0200 @@ -10,6 +10,7 @@ 'django.db.backends.postgresql_psycopg2': 'postgresql_psycopg2', 'django.db.backends.sqlite3': 'sqlite3', 'django.db.backends.mysql': 'mysql', + 'mysql_oursql.standard': 'mysql', 'django.db.backends.oracle': 'oracle', 'sql_server.pyodbc': 'sql_server.pyodbc', #django-pyodbc 'sqlserver_ado': 'sql_server.pyodbc', #django-mssql }}}",samfiragabriel@… Active Tickets,1237,MSSQL (Azure SQL Server 2012) Can't create tables,commands,unknown,,enhancement,andrew,new,2013-03-30T13:26:47Z,2013-03-30T13:26:47Z,"Looks like Azure SQL Server enforces to create CLUSTERED INDEXES so you can't make south migrations when connecting to a MSSQL Database in the cloud through pyodbc. '''pyodbc.ProgrammingError: ('42000', '[42000] [Microsoft][SQL Server Native Client 11.0][SQL Server]Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again. (40054) (SQLExecDirectW)')''' ",anonymous Active Tickets,208,Error in auto-migration when deleting a reference to object,migrations,0.5,0.6,defect,andrew,reopened,2009-07-16T08:15:49+01:00,2010-06-26T14:25:23+01:00,"Models layout like this:[[BR]] class Job:[[BR]] route = models.ForeignKey('Route')[[BR]] ...[[BR]][[BR]] class Route:[[BR]] ...[[BR]] [[BR]] When removing Route reference from Job class and running ./manage.py startmigration my_application delete --auto following exception occurs: - Deleted field 'my_application.job.route' Traceback (most recent call last): File ""./manage.py"", line 14, in execute_manager(settings) File ""/var/lib/python-support/python2.6/django/core/management/__init__.py"", line 340, in execute_manager utility.execute() File ""/var/lib/python-support/python2.6/django/core/management/__init__.py"", line 295, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/var/lib/python-support/python2.6/django/core/management/base.py"", line 192, in run_from_argv self.execute(*args, **options.__dict__) File ""/var/lib/python-support/python2.6/django/core/management/base.py"", line 219, in execute output = self.handle(*args, **options) File ""/usr/local/lib/python2.6/dist-packages/South-0.5-py2.6.egg/south/management/commands/startmigration.py"", line 401, in handle deps = field_dependencies(field, last_models) File ""/usr/local/lib/python2.6/dist-packages/South-0.5-py2.6.egg/south/management/commands/startmigration.py"", line 659, in field_dependencies depends.update(stub_model_dependencies(field.rel.to, last_models)) File ""/usr/local/lib/python2.6/dist-packages/South-0.5-py2.6.egg/south/management/commands/startmigration.py"", line 653, in stub_model_dependencies return field_dependencies(model._meta.pk, last_models) AttributeError: 'str' object has no attribute '_meta'",artem.skvira@… Active Tickets,498,Migration from field to ForeignKey with same name fails,commands,0.7.1,0.7.2,defect,andrew,reopened,2010-07-02T13:15:28+01:00,2013-04-08T04:36:26+01:00,"First model {{{ class Test(models.Model): logo = models.ImageField(upload_to=""path"") }}} Second model {{{ class Logo(models.Model): image = models.ImageField(upload_to=""path"") class Test(models.Model): logo = models.ForiegnKey(Logo) }}} South generates following migrations : {{{ # Renaming column for 'Coupon.logo' to match new field type. db.rename_column('coupon_coupon', 'logo', 'logo_id') # Changing field 'Coupon.logo' db.alter_column('coupon_coupon', 'logo_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['coupon.Logo'])) # Adding index on 'Coupon', fields ['logo'] db.create_index('coupon_coupon', ['logo_id']) }}} and this migrations fails on PostgeSQL with error: {{{ django.db.utils.DatabaseError: column ""logo_id"" cannot be cast to type integer }}} ",shaper.int@… Active Tickets,220,Renaming a inherited model makes troubles with foreignkeys,commands,0.6-pre,1.0,defect,andrew,assigned,2009-07-29T14:11:53+01:00,2010-08-13T14:54:32+01:00,"If i rename a table that was inherited from an other model there are some issues: the primary_key changes name MySQL MyIsam doesn't allow to rename primary keys MySQL InnoDB and Postgres have troubles with foreingkey constraints ",anonymous Active Tickets,334,Allow loaddata usage with the frozen ORM,migrations,0.7-pre,1.0,defect,andrew,assigned,2010-02-05T22:53:54Z,2013-03-11T23:43:05Z,"Currently, loaddata relies on models looking roughly the same; there should really be a way to load data from inside a migration, using the fake ORM.",andrew Active Tickets,336,Try to stop the auth module's superuser hook from firing when a profile module is defined,commands,0.6.2,1.0,defect,andrew,assigned,2010-02-06T13:44:14Z,2010-08-13T14:54:59+01:00,"If the profile module is migrated, the tables won't be ready yet, and so the hook will fail catastrophically.",andrew Active Tickets,358,Automatically detect column renames,commands,0.6.2,1.0,defect,andrew,assigned,2010-02-23T22:33:54Z,2010-05-21T21:10:02+01:00,,andrew Active Tickets,391,_ptr fields in inheriting models not renamed when main model is renamed,commands,0.7-rc1,1.0,defect,andrew,assigned,2010-03-21T18:20:20Z,2010-12-01T19:56:45Z,"For example, if I have: {{{ model Foo: x = CharField() model Bar(Foo): pass }}} and rename Foo to Baz, the `foo_ptr` field on Bar is not renamed to `baz_ptr`.",andrew Active Tickets,407,Can't alter column to AutoField on postgreSQL,migrations,0.7,1.0,defect,andrew,assigned,2010-03-29T18:16:01+01:00,2013-03-17T14:39:11Z,"After testing my case in ticket #402 I tried it out on postgreSQL and came across the following error: django.db.utils.DatabaseError: type ""serial"" does not exist I think the problem comes down to the discussion here: http://old.nabble.com/ALTER-TABLE-with-TYPE-serial-does-not-work-td21769575.html",pjrharley@… Active Tickets,426,Replace __import__ with import_module,commands,mercurial,1.0,defect,andrew,assigned,2010-04-16T01:09:09+01:00,2010-08-13T15:51:42+01:00,"The `fromlist` parameter of `__import__` is poorly documented and implemented; specifically when importing a package and `fromlist` contains an empty string, the package is imported twice with a bogus `__name__` the second time (see http://bugs.python.org/issue2090). This resulted to an obscure bug during an initial migration I ran. Attached is a patch that replaces all `__import__` calls with `django.utils.importlib.import_module` (also to be included in Python 2.7). ",george.sakkis@… Active Tickets,431,db.alter_column() cannot change default value in MySQL,databaseapi,0.7,1.0,defect,andrew,assigned,2010-04-19T10:07:11+01:00,2011-08-26T03:18:35+01:00,"Here is my server information: * mysql 5.0.51a * ubuntu 8.04 Using db.alter_column() to change the default value works in sqlite3 but fails in MySQL. models.py: {{{ class Name(models.Model): n = models.IntegerField(default=3) }}} Part of the migration script: {{{ class Migration(SchemaMigration): def forwards(self, orm): db.alter_column('my_app_name', 'n', models.IntegerField(default=40)) def backwards(self, orm): db.alter_column('my_app_name', 'n', models.IntegerField(default=3)) }}} After running ""migrate"" (forward or backward), the default value is changed to None. ",fcamel@… Active Tickets,434,Ordering of items in a Migration leads to error,migrations,0.7,1.0,defect,andrew,assigned,2010-04-20T08:32:02+01:00,2010-09-14T17:06:50+01:00,"I generated a schema migration which contained the following lines: {{{ class Migration(SchemaMigration): def forwards(self, orm): # Deleting field 'Asset.type' db.delete_column('assetversions_asset', 'type_id') # Changing field 'Asset.category' db.alter_column('assetversions_asset', 'category_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['AssetVersions.AssetCategory'])) # Removing unique constraint on 'Asset', fields ['project', 'type', 'name'] db.delete_unique('assetversions_asset', ['project_id', 'type_id', 'name']) # Adding unique constraint on 'Asset', fields ['project', 'category', 'name'] db.create_unique('assetversions_asset', ['project_id', 'category_id', 'name']) }}} Not surprisingly this fails when executed, since the constraint on the Asset.type field isn't deleted (in the third command) until after the column itself is deleted (in the first command). I'm using MySQL (and yes I know it doesn't have transaction support for schema changes) but it sure seems reasonable that any database would be upset about deleting a column before deleting a constraint on that column. Is it feasible to change south to always generate deletions of constraints first within a migration? The context (not sure if it matters or not but just to be clear) is that I'm doing a three-step schema-data-schema migration. Asset used to have a ForeignKey on AssetType, but now it has a ForeignKey on AssetCategory which links to on AssetType. This error happens in the third step when I'm cleaning up the old AssetType link and the unique_together constraint that goes with it. I also ran into the already-fixed bug in ticket #403 because of my data migration wasn't bug-free on the first try ;-). Thanks for the fix on that! Obviously, I can (and did) work around this easily once I found it. I edited the migration file and put the delete of the old constraint first in the forwards() method. So in that sense, it's not a critical problem. But it is exactly the sort of thing I want the migrations layer to handle for me so I don't have to think about it every time! Leo P.S. And to be clear even though I'm filing a ticket... south is awesome and I really appreciate it! This is my first south project so apologies for not knowing the code well enough to suggest a patch. ",leovitch Active Tickets,435,"Changing a ForeignKey from a ""real"" model to a proxy of it generates invalid migration code",migrations,0.7,1.0,defect,andrew,assigned,2010-04-21T13:43:12+01:00,2010-12-01T20:37:25Z,"Steps to reproduce: 1) Have a model with a ForiegnKey to e.g. auth.User 2) create & run migration 3) Add a ProxyModel of auth.User (in my example ""FilerUser"") 4) try to create migration (nothing to be done) 5) Change ForiegnKey on first Model to use the Proxy 6) create migration - invalid python code results (see below) {{{ class Migration(SchemaMigration): def forwards(self, orm): # Adding model 'FilerUser' db.create_table('auth_user', ( , )) db.send_create_signal('filer', ['FilerUser']) def backwards(self, orm): # Deleting model 'FilerUser' db.delete_table('auth_user') }}} Even worse than the broken forwards migration is the backwards one which would delete the base of the proxy model.",Ulrich Petri Active Tickets,451,South seems to break get_profile in test mode,migrations,0.7,1.0,defect,andrew,assigned,2010-05-03T14:09:29+01:00,2011-08-29T01:44:22+01:00,"When executing the code below in test mode (./manage.py test) profile = request.user.get_profile() profile.related_field Problem here is that class name has changed - 'relatedfield' should be RelatedField. as soon as I turn off migrations for testing, with SOUTH_TESTS_MIGRATE = False problem goes away. ",artem.skvira@… Active Tickets,466,Renaming a foreign key doesn't update the foreign key in MySQL with InnoDB,migrations,0.7,1.0,defect,andrew,assigned,2010-05-20T15:29:55+01:00,2011-07-07T22:11:37+01:00,The index seems to be updated but not the actual fk that is used to follow cascades and so on. This actually doesn't seem to cause too many problems until you try to do another alteration to the same table and you start getting seemingly unrelated errors about incorrect foreign keys.,KyleMac Active Tickets,470,Migrations scripts from 0.6 fail with 0.7.1 due to inheritance problem,commands,unknown,1.0,defect,andrew,assigned,2010-06-02T08:36:02+01:00,2010-12-01T20:38:12Z,"I had following case: First I added new column ""rank"" to a table of the class ""CollatedRecordingStat"" (see 0004_added_rank_field_to_collated_recordings.py). Later on I moved ""rank"" into the table of the superclass ""CollatedStat"" (see 0006_generalize_collatedstats.py). The scripts were created with South 0.6, but when I switched to 0.7.1 (due to Django 1.2) the scripts fail. You'll find the complete output of the migration including the traceback here http://pastebin.com/yzkCKG4R ",christian.h@… Active Tickets,477,Related models from a parent model that has been inherited are not available in migrations,migrations,0.7.1,1.0,defect,andrew,assigned,2010-06-07T17:02:49+01:00,2010-08-17T09:31:32+01:00,"If you migrate a child model then the parent is available on the orm but foreign keys to and from the parent model are not. This comes into play with data migratons as you can't update related fields from the child model, and there's no way to do it the other way round (i.e. do all children from the parent) because the parent rightly has no idea about the children.",KyleMac Active Tickets,478,"db.delete_index() doesn't introspect the database to get the name of index, fails with django 1.2",databaseapi,mercurial,1.0,defect,andrew,assigned,2010-06-09T00:22:28+01:00,2011-07-22T07:08:06+01:00,"South uses django < 1.2 conventions to work out names of indexes in db.delete_indexes(), thus failing to get the right indexes with django 1.2. Ideally, it should rely on db introspection instead. I'm seeing this on mysql, django 1.2, south@tip.",gciotta@… Active Tickets,570,Syntax Error!!!,commands,unknown,1.0,defect,andrew,reopened,2010-08-28T16:45:52+01:00,2013-05-03T05:19:57+01:00,"{{{ Creating test database 'default'... Skipping creation of NoticeTypes as notification app not found Skipping creation of NoticeTypes as notification app not found Traceback (most recent call last): File ""./myproject/manage.py"", line 11, in execute_manager(settings) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/usr/local/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/local/lib/python2.6/dist-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/home/satels/south-read-only/south/management/commands/test.py"", line 8, in handle super(Command, self).handle(*args, **kwargs) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/commands/test.py"", line 37, in handle failures = test_runner.run_tests(test_labels) File ""/usr/local/lib/python2.6/dist-packages/django/test/simple.py"", line 313, in run_tests old_config = self.setup_databases() File ""/usr/local/lib/python2.6/dist-packages/django/test/simple.py"", line 270, in setup_databases connection.creation.create_test_db(self.verbosity, autoclobber=not self.interactive) File ""/usr/local/lib/python2.6/dist-packages/django/db/backends/creation.py"", line 356, in create_test_db call_command('syncdb', verbosity=max(verbosity - 1, 0), interactive=False, database=self.connection.alias) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 166, in call_command return klass.execute(*args, **defaults) File ""/usr/local/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/django/core/management/base.py"", line 351, in handle return self.handle_noargs(**options) File ""/home/satels/south-read-only/south/management/commands/syncdb.py"", line 99, in handle_noargs management.call_command('migrate', **options) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 166, in call_command return klass.execute(*args, **defaults) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/home/satels/south-read-only/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/home/satels/south-read-only/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/home/satels/south-read-only/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/home/satels/south-read-only/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/home/satels/south-read-only/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/home/satels/south-read-only/south/migration/migrators.py"", line 99, in run return self.run_migration(migration) File ""/home/satels/south-read-only/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/home/satels/south-read-only/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/home/satels/workspace/myproject/myproject/projects/migrations/0001_add_user_section.py"", line 12, in forwards db.add_column('projects_project', 'author', self.gf('django.db.models.fields.related.ForeignKey')(default=1, to=orm['auth.User']), keep_default=False) File ""/home/satels/south-read-only/south/db/sqlite3.py"", line 33, in add_column field.column: self._column_sql_for_create(table_name, name, field, False), File ""/home/satels/south-read-only/south/db/sqlite3.py"", line 79, in _remake_table self._copy_data(table_name, temp_name, renames) File ""/home/satels/south-read-only/south/db/sqlite3.py"", line 105, in _copy_data self.quote_name(src), File ""/home/satels/south-read-only/south/db/generic.py"", line 137, in execute cursor.execute(sql, params) File ""/usr/local/lib/python2.6/dist-packages/django/db/backends/sqlite3/base.py"", line 200, in execute return Database.Cursor.execute(self, query, params) django.db.utils.DatabaseError: near "")"": syntax error }}} ",anonymous Active Tickets,599,PointField error,commands,unknown,1.0,defect,andrew,assigned,2010-10-11T22:04:52+01:00,2013-04-01T04:16:19+01:00,"I'm trying to convert some geodjango models to South. I got this error: File ""/home/django/applications/nims-groups/groups/migrations/0001_initial.py"", line 29 ('point', self.gf('django.contrib.gis.db.models.fields.PointField')(default=, null=True, blank=True)), ^ SyntaxError: invalid syntax The pointer starts at "" bin/test ... Creating test database... Syncing... Creating table aaa Creating table bbb ... No fixtures found. Migrating... Running migrations for ccc: - Migrating forwards to 0001_initial. ... No fixtures found. Synced: > aaa > bbb Migrated: - ccc Creating test database 'the_second_database'... Syncing... Creating table ddd Creating table eee No fixtures found. Migrating... Traceback (most recent call last): ... django.db.utils.DatabaseError: no such table: south_migrationhistory }}} What to do about this? A workaround is to add SOUTH_TESTS_MIGRATE = False to my settings.py, btw.",reinout@… Active Tickets,724,South fails to migrate OneToOne to ForeginKey,migrations,0.7.3,1.0,defect,andrew,assigned,2011-02-22T22:17:45Z,2012-07-16T22:07:50+01:00,"I'm using django 1.3 beta. When trying to migrate from OneToOne field to ForeginKey field South fails with exception: {{{ Running migrations for southbug: - Migrating forwards to 0002_auto__chg_field_testmodel2_fk__del_unique_testmodel2_fk. > southbug:0001_initial > southbug:0002_auto__chg_field_testmodel2_fk__del_unique_testmodel2_fk ! 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 `southbug_testmodel2` ADD CONSTRAINT `southbug_testmodel2_fk_id_uniq` UNIQUE (`fk_id`) [] ! 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 11, in execute_manager(settings) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 99, in run return self.run_migration(migration) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/home/jb/programs/wnt/zlotKadryRejestracja/southbug/migrations/0002_auto__chg_field_testmodel2_fk__del_unique_testmodel2_fk.py"", line 12, in forwards db.delete_unique('southbug_testmodel2', ['fk_id']) File ""/home/jb/programs/wnt/zlotKadryRejestracja/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 southbug_testmodel2, columns ['fk_id'] }}} If you comment out appopriate db.delete_unique('rejestracja_validatorzajecialink', ['zajecia_id']) i get: {{{ - Migrating forwards to 0003_auto__chg_field_validatorkurslink_validator__del_unique_validatorkursl. > rejestracja:0003_auto__chg_field_validatorkurslink_validator__del_unique_validatorkursl ! 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 `rejestracja_validatorkurslink` ADD CONSTRAINT `rejestracja_validatorkurslink_validator_id_uniq` UNIQUE (`validator_id`) [] = ALTER TABLE `rejestracja_validatorkurslink` ADD CONSTRAINT `rejestracja_validatorkurslink_kurs_id_uniq` UNIQUE (`kurs_id`) [] = ALTER TABLE `rejestracja_validatorzajecialink` ADD CONSTRAINT `rejestracja_validatorzajecialink_validator_id_uniq` UNIQUE (`validator_id`) [] = ALTER TABLE `rejestracja_validatorzajecialink` ADD CONSTRAINT `rejestracja_validatorzajecialink_zajecia_id_uniq` UNIQUE (`zajecia_id`) [] ! 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 11, in execute_manager(settings) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 99, in run return self.run_migration(migration) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/home/jb/programs/wnt/zlotKadryRejestracja/rejestracja/migrations/0003_auto__chg_field_validatorkurslink_validator__del_unique_validatorkursl.py"", line 24, in forwards db.alter_column('rejestracja_validatorkurslink', 'validator_id', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['rejestracja.Validator'])) File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/db/generic.py"", line 397, in alter_column field.rel.to._meta.get_field(field.rel.field_name).column File ""/home/jb/programs/wnt/zlotKadryRejestracja/south/db/generic.py"", line 150, in execute cursor.execute(sql, params) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/db/backends/util.py"", line 34, in execute return self.cursor.execute(sql, params) File ""/home/jb/programs/wnt/zlotKadryRejestracja/django/db/backends/mysql/base.py"", line 86, in execute return self.cursor.execute(query, args) File ""/usr/lib/pymodules/python2.6/MySQLdb/cursors.py"", line 166, in execute self.errorhandler(self, exc, value) File ""/usr/lib/pymodules/python2.6/MySQLdb/connections.py"", line 35, in defaulterrorhandler raise errorclass, errorvalue _mysql_exceptions.OperationalError: (1005, ""Can't create table 'rejestracja-2011.#sql-5b2_13c' (errno: 121)"") }}} ",jbzdak@… Active Tickets,736,Migration with proxy model does not work,commands,0.7.3,1.0,defect,andrew,assigned,2011-03-15T16:02:24Z,2011-08-25T15:31:35+01:00,"This is somewhat duplicate of old ticket http://south.aeracode.org/ticket/436 but it was so old, i made new one. I use django.contrib.auth.models.User as foreign key in my table, and to get it ordered right, i need to use Proxy-model like this {{{ class OrderedUser(User): class Meta: proxy = True ordering = [""username"",] }}} (from django documentation: http://docs.djangoproject.com/en/dev/topics/db/models/#proxy-models) Then I use it in my model {{{ user = models.ForeignKey(OrderedUser) }}} When I do ./manage.py shemamigration --auto app it says {{{ + Added model app.OrderedUser Created 0002_auto__add_ordereduser.py. You can now apply this migration with: ./manage.py migrate app }}} I'm using South 0.7.3, so this should be fixed. Why is it not ignored? In migration file, there's {{{ def forwards(self, orm): # Adding model 'OrderedUser' db.create_table('auth_user', ( , )) db.send_create_signal('app', ['OrderedUser']) }}} Which - of course - results an error.",jazmo@… Active Tickets,745,Wrong column type for OneToOneField w/ parent_link=True,migrations,0.7.3,1.0,defect,andrew,assigned,2011-03-24T16:06:38Z,2011-03-25T10:33:50Z,"When models' pks are defined by a OneToOneField with parent_link=True, South seems to not recognize this and incorrectly gives foreign keys to those models the default pk type of integer. In the case that the pk is actually something else (bigint in my case).. You end up with mis-matched column types. Tested in 0.7.1 and 0.7.3 class ModelA(models.Model): id = models.BigIntegerField(primary_key=True) class ModelB(ModelA): a_id = models.OneToOneField(ModelA, parent_link=True) >> ModelB._meta.pk.db_type() 'bigint' >> orm['app.ModelB']._meta.pk.db_type() 'integer AUTO_INCREMENT' ",famousactress@… Active Tickets,746,datamigrations with proxy model m2m has invalid manager,commands,0.7.3,1.0,defect,andrew,assigned,2011-03-25T07:21:05Z,2011-03-25T10:26:33Z,"Given the following models: {{{ class Worker(User): class Meta: proxy = True class Task(models.Model): creator = models.ForeignKey(Worker, related_name='created_tasks') assignees = models.ManyToManyField(Worker, related_name='assigned_tasks', blank=True, null=True) }}} Trying to add Worker instances to the assignees m2m manager in datamigration raises an exception since the wrong field name is given on creation of the field. {{{ def forwards(self, orm): # Workaround... #orm.Task.assignees.through._meta.fields[2].attname = 'worker_id' #orm.Task.assignees.through._meta.fields[2].name = 'worker' #orm.Task.assignees.through._meta.fields[2].column = 'worker_id' for t in orm.Task.objects.all(): t.assignees.add(t.creator) t.save() }}} Without the commented ''workaround'' it raises: {{{ ... File ""/home/simon/.local/share/Trash/files/proxy_class_manager_issue/app/migrations/0002_bugged_assign_task_assignees.py"", line 15, in forwards t.assignees.add(t.creator) File ""/usr/local/lib/python2.7/dist-packages/django/db/models/fields/related.py"", line 503, in add self._add_items(self.source_field_name, self.target_field_name, *objs) File ""/usr/local/lib/python2.7/dist-packages/django/db/models/fields/related.py"", line 575, in _add_items new_ids = new_ids - set(vals) File ""/usr/local/lib/python2.7/dist-packages/django/db/models/query.py"", line 107, in _result_iter self._fill_cache() File ""/usr/local/lib/python2.7/dist-packages/django/db/models/query.py"", line 772, in _fill_cache self._result_cache.append(self._iter.next()) File ""/usr/local/lib/python2.7/dist-packages/django/db/models/query.py"", line 956, in iterator for row in self.query.get_compiler(self.db).results_iter(): File ""/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py"", line 680, in results_iter for rows in self.execute_sql(MULTI): File ""/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py"", line 735, in execute_sql cursor.execute(sql, params) File ""/usr/local/lib/python2.7/dist-packages/django/db/backends/util.py"", line 34, in execute return self.cursor.execute(sql, params) File ""/usr/local/lib/python2.7/dist-packages/django/db/backends/sqlite3/base.py"", line 234, in execute return Database.Cursor.execute(self, query, params) django.db.utils.DatabaseError: no such column: app_task_assignees.user_id }}} I'm attaching a small project to reproduce the issue, just run syncdb --migrate and it will trigger the error.",charette.s@… Active Tickets,755,"Oracle DB does not work , sql incorrect.",databaseapi,0.7.3,1.0,defect,andrew,assigned,2011-04-10T09:51:22+01:00,2011-04-15T19:10:41+01:00,"The issue having ""unique"" with ""defaults"". site-packages\south\db\generic.py def column_sql(self, table_name, field_name, field, tablespace='', with_name=True, field_prepared=False): '''Instead of :''' {{{ elif (not field.null and field.blank) or (field.get_default() == ''): }}} '''the change:''' {{{ elif (not field.unique and not field.null and field.blank) or (not field.unique and field.get_default() == ''): }}} It didn't like unique with default … which makes sense I should have done it : {{{ elif not field.unique and ((not field.null and field.blank) or (field.get_default() == '')): }}} ",saffi.public@… Active Tickets,781,Model Instances not valid when used as arguments for creating another object,migrations,0.7.3,1.0,defect,andrew,assigned,2011-06-03T01:17:21+01:00,2011-11-29T15:33:49Z,"I'm having trouble with creating new objects in a datamigration. When using object instances from the South orm, e.g. content_type_instance = orm['contenttypes.ContentType'].objects.get(**ct_kwargs) to create another object: publishing_kwargs = { 'site': site if isinstance(site, Site) else Site.objects.get(id=site.id), 'publishing_type': publishing_type_instance, 'start': start, 'content_type': content_type_instance, 'object_id': content_object.id, } publishing = orm.Publishing(**publishing_kwargs) I get a ValueError: Cannot assign """": ""Publishing.content_type"" must be a ""ContentType"" instance. See also: http://stackoverflow.com/questions/6211027/south-data-migration-instance-error-when-using-south-freeze-orm/6215957#6215957 http://dpaste.com/hold/549891/ ",daryl@… Active Tickets,782,Integrity appears after removing null=True from field,migrations,0.7.3,1.0,defect,andrew,assigned,2011-06-06T19:23:26+01:00,2012-06-14T20:25:49+01:00,"I have a field called `cc_zip_code` which previously was allowed to be null. I just changed removed `null=True` from the field definition. After creating and running the migration, South throws an IntegrityError on the field. {{{ Running migrations for app: - Migrating forwards to 0033_auto__chg_field_client_cc_zip_code__chg_field_client_cc_exp_month__chg. > app:0031_auto__del_field_client_name__del_field_client_cc_first_name__del_field > app:0032_auto__del_field_client_cc_token__del_field_client_cc_invalid__del_fiel > app:0033_auto__chg_field_client_cc_zip_code__chg_field_client_cc_exp_month__chg Traceback (most recent call last): File ""./manage.py"", line 14, in execute_manager(settings) File ""/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/usr/local/lib/python2.7/site-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/local/lib/python2.7/site-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/usr/local/lib/python2.7/site-packages/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/usr/local/lib/python2.7/site-packages/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 99, in run return self.run_migration(migration) File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/usr/local/lib/python2.7/site-packages/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/Users/dan/Web/codeyouridea/app/migrations/0033_auto__chg_field_client_cc_zip_code__chg_field_client_cc_exp_month__chg.py"", line 12, in forwards db.alter_column('app_client', 'cc_zip_code', self.gf('django.db.models.fields.CharField')(default='90212', max_length=9)) File ""/usr/local/lib/python2.7/site-packages/south/db/sqlite3.py"", line 180, in alter_column name: self._column_sql_for_create(table_name, name, field, explicit_name), File ""/usr/local/lib/python2.7/site-packages/south/db/sqlite3.py"", line 83, in _remake_table self._copy_data(table_name, temp_name, renames) File ""/usr/local/lib/python2.7/site-packages/south/db/sqlite3.py"", line 114, in _copy_data self.quote_name(src), File ""/usr/local/lib/python2.7/site-packages/south/db/generic.py"", line 150, in execute cursor.execute(sql, params) File ""/usr/local/lib/python2.7/site-packages/django/db/backends/util.py"", line 34, in execute return self.cursor.execute(sql, params) File ""/usr/local/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py"", line 234, in execute return Database.Cursor.execute(self, query, params) django.db.utils.IntegrityError: _south_new_app_client.cc_zip_code may not be NULL }}} If I try to run the migration again, it says: {{{ django.db.utils.DatabaseError: table ""_south_new_app_client"" already exists }}}",dloewenherz@… Active Tickets,789,Mark Migration: downtime=True,commands,unknown,1.0,defect,andrew,assigned,2011-06-16T10:35:40+01:00,2011-06-16T10:40:57+01:00,"Some migrations take long. I want to mark these migrations, since I don't want to execute them during normal work hours. My solution, would be a attribute downtime=True in the migration class. It would be nice if ""migrate --list"" would display this. Or a note would be a solution: If a migration has a note, it will be displayed. This is a more general solution.",hv@… Active Tickets,814,Patch from #421 doesn't check for uppercase,databaseapi,0.7.3,1.0,defect,andrew,assigned,2011-07-28T18:29:00+01:00,2011-08-26T03:53:23+01:00,"The patch provided with http://south.aeracode.org/ticket/421 does not check if the column type is 'TEXT' or 'BLOB' (upper case), causing south to fail if a field reports its column type as uppercase",reames@… Active Tickets,955,Don't create migrations for built-in apps,commands,0.7.3,1.0,defect,andrew,infoneeded,2011-11-16T23:56:13Z,2011-11-17T00:16:15Z,"Running {{{ python manage.py schemamigration auth --auto }}} fails, as it should. However, in the process, south creates a migrations directory inside `site-packages/django/contrib/auth`! As a result, the next `python manage.py syncdb` fails, because it expects south to be managing the `contrib.auth` tables, but south isn't. Trying the obvious debugging steps as a user doesn't work: Dropping and recreating the database doesn't help, nor does rolling back your working code, because south has written to your virtualenv / global installation of Django. This is very surprising behavior for a failed command, and as I can testify, it can take hours as an unsuspecting user to track down what happened to get you into a bad state. Part of the answer is ""don't do that!"", but some idiot-proofing would be nice. :) I would suggest two possible fixes: (1) When `schemamigration --auto` fails because it needed to be `--initial` instead, don't create a migrations directory, or delete the one that got created. (2) Refuse to do anything migration-related for apps in `site-packages`, or at least issue a very loud warning. ",josharian+south@… Active Tickets,994,"add_column(PositiveIntegerField, keep_default=False) create greater zero constraint twice",commands,unknown,1.0,defect,andrew,accepted,2012-01-16T15:59:22Z,2012-01-16T16:03:05Z,"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 }}} ",guettli Active Tickets,1019,"A New Trend Sees the Web Come Alive As ""Livespots"" Proliferate",commands,unknown,1.0,defect,andrew,new,2012-01-29T13:17:49Z,2012-01-29T13:17:49Z,"All additional documents are copies golden girls and can be destroyed when they are no longer referenced frequently.If you selling body jewelry golden girls online, individuals could be good keywords to use in your domain person's term.In Google Video player there is an option on behalf of pointed video which is really very powerful.There's a allocation to find out, but it prerequisite not be painful.D=�]�₵���̹t_�l~JD�I��J��tOÉؔqY�ƒ��3[D���\�01���z�S4)�eM kF�9�z����q4Í»�i��F��:=�>�g|��",midgeybt Active Tickets,1024,retry_failed_fields methods fails to produce meaningfull error if exception message contains unicode chars,commands,unknown,1.0,defect,andrew,accepted,2012-02-05T10:27:30Z,2012-02-05T11:53:03Z,"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 }}}",jbzdak@… Active Tickets,1049,unique_together ordering,commands,unknown,1.0,defect,andrew,accepted,2012-03-05T15:42:51Z,2012-06-26T21:54:42+01:00,"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?). ",George Lund Active Tickets,1070,"migration fails with m2m field, with certain attributes defined, pointing proxy model",commands,0.7.4,1.0,defect,andrew,assigned,2012-04-25T20:41:23+01:00,2012-04-26T11:16:02+01:00,"This one is similar to [http://south.aeracode.org/ticket/496 ticket #496], if not of the same problem. I am actually using South v0.7.4 (not available from the pull-down). It appears that there is a problem migrating applications that have a model with a ManyToManyField pointing to a proxy model (in my case, it's a proxy model for django's User model). Below is the code for my case: {{{ class ExtendedUser(User): class Meta: proxy = True class Item(Model): ... watchers = models.ManyToManyField(ExtendedUser, related_name='watching_items') ... }}} I created initial migration with the above model definitions. As soon as I tried to migrate it, I got the following error: {{{ KeyError: ""The model 'extendeduser' from the app 'lend_borrow' is not available in this migration."" }}} So I inspected the migration and found the following trouble: {{{ db.create_table('lend_borrow_item_watchers', ( ('id', models.AutoField(verbose_name='ID', primary_key=True, auto_created=True)), ('item', models.ForeignKey(orm['lend_borrow.item'], null=False)), ('extendeduser', models.ForeignKey(orm['lend_borrow.extendeduser'], null=False)) )) db.create_unique('lend_borrow_item_watchers', ['item_id', 'extendeduser_id']) }}} The prolem is the '''lend_borrow.extendeduser''' in the above code, which should have been '''auth.user'''. Also, for the sake of completeness, the names auto-generated based on the name of the proxy model, ExtendedUser, should also have been based on the actual underlying model, User, instead. In the same model, Item, there's another ManyToManyField pointing to the said proxy model, ExtendedUser. {{{ class Item(Model): ... requesters = models.ManyToManyField(ExtendedUser, through='ItemRequest') ... }}} But what's interesting here is that the migration has correct entries for this ManyToManyField and thus no issue. From the look of it, this issue occurs only on ManyToManyField with certain conditions met (in my case, it has ''related_name'' and no ''through'').",waterbotte@… Active Tickets,1177,Error when a m2m relationship is defined between one south app and one non-south app where non-south app has initial data.,commands,unknown,1.0,defect,andrew,new,2012-09-20T18:43:03+01:00,2013-05-04T18:32:07+01:00,"During a syncdb, when an app has initial data, Django resets the sequence for the primary key on the model table, and the the primary key on any manytomany tables (see lines 246-252 of core/management/commands/loaddata.py). If a non-south app has an m2m relationship to a south app, the non-south app will attempt to reset sequences for tables that have not yet been created and, in doing so, will error out. To reproduce, create an initial_data.json fixture for django.contrib.auth.Group and define a model in a south-enabled app that has an m2m relationship to Group. Then, attempt to run syncdb. You will see an error similar to the following: DatabaseError: relation ""actstream_action"" does not exist LINE 1: ...alesce(max(""id""), 1), max(""id"") IS NOT null) FROM ""actstream... The simplest solution I can see here is to do the load_data ""stuff"" after running migrate. That way, all tables will be installed.",joshua.fialkoff@… Active Tickets,1180,primary key in model is not primary key in database,migrations,mercurial,1.0,defect,andrew,assigned,2012-10-02T12:24:43+01:00,2012-10-03T17:06:24+01:00,"I've recently started using Django for a smallish project. I am also using South to help with migration. At the moment I'm developing models but have noticed a possible bug A ""primary key"" created in the model is not a ""primary key"" in the Postgres db but ""unique"" is this a bug? The sqlall code suggest that it is attempting to create a table with the right structure, but the database shows the field to be ""unique"" and not ""primary key"" ==Model info== {{{ from django.db import models # Create your models here. class ModelTest(models.Model): pkey=models.CharField(max_length=20, primary_key=True) ukey=models.CharField(max_length=20,unique=True) }}} ==sqlall info== {{{ C:\dev\patinbox>python manage.py sqlall micropat_db BEGIN; CREATE TABLE ""micropat_db_modeltest"" ( ""pkey"" varchar(20) NOT NULL PRIMARY KEY, ""ukey"" varchar(20) NOT NULL UNIQUE ) ; }}} ==Extract from postgres database (version 9.1)== {{{ -- Table: micropat_db_modeltest -- DROP TABLE micropat_db_modeltest; CREATE TABLE micropat_db_modeltest ( pkey character varying(20) NOT NULL, ukey character varying(20) NOT NULL, CONSTRAINT micropat_db_modeltest_pkey_uniq UNIQUE (pkey ), CONSTRAINT micropat_db_modeltest_ukey_key UNIQUE (ukey ) ) WITH ( OIDS=FALSE ); ALTER TABLE micropat_db_modeltest OWNER TO postgres; }}}",ccruickshank Active Tickets,1188,Fails creating PostGIS PointFields with db_index=True,migrations,0.7.6,1.0,defect,andrew,new,2012-11-11T18:21:22Z,2012-11-11T18:21:22Z,"When using PostGIS and creating a PointField with a parameter of db_index=True, south's migrations fails. Removing db_index=True from the autogenerated migration results in a working migration {{{ location = models.PointField(blank=True, null=True, db_index=True, help_text=""foo"") }}} {{{ ./manage.py schemamigration core --auto + Added model core.Itinerary Created 0058_auto__add_itinerary.py. You can now apply this migration with: ./manage.py migrate core }}} {{{ ./manage.py migrate core Skipping creation of NoticeTypes as notification app not found Running migrations for core: - Migrating forwards to 0058_auto__add_itinerary. > core:0058_auto__add_itinerary Error in migration: core:0058_auto__add_itinerary Traceback (most recent call last): File ""./manage.py"", line 14, in execute_manager(settings) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/usr/local/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/local/lib/python2.6/dist-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/local/lib/python2.6/dist-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/srv/django/myproject/south/management/commands/migrate.py"", line 108, in handle ignore_ghosts = ignore_ghosts, File ""/srv/django/myproject/south/migration/__init__.py"", line 213, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/srv/django/myproject/south/migration/migrators.py"", line 235, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/srv/django/myproject/south/migration/migrators.py"", line 310, in migrate_many result = self.migrate(migration, database) File ""/srv/django/myproject/south/migration/migrators.py"", line 133, in migrate result = self.run(migration) File ""/srv/django/myproject/south/migration/migrators.py"", line 107, in run return self.run_migration(migration) File ""/srv/django/myproject/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/srv/django/myproject/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/srv/django/myproject/core/migrations/0058_auto__add_itinerary.py"", line 20, in forwards ('info', self.gf('django.db.models.fields.TextField')()), File ""/srv/django/myproject/south/db/generic.py"", line 44, in _cache_clear return func(self, table, *args, **opts) File ""/srv/django/myproject/south/db/generic.py"", line 347, in create_table for field_name, field in fields File ""/srv/django/myproject/south/db/generic.py"", line 726, in column_sql for stmt in self._get_connection().creation.sql_indexes_for_field(model, field, no_style()): File ""/usr/local/lib/python2.6/dist-packages/django/contrib/gis/db/backends/postgis/creation.py"", line 12, in sql_indexes_for_field output = super(PostGISCreation, self).sql_indexes_for_field(model, f, style) File ""/usr/local/lib/python2.6/dist-packages/django/db/backends/postgresql/creation.py"", line 68, in sql_indexes_for_field if db_type.startswith('varchar'): AttributeError: 'NoneType' object has no attribute 'startswith' }}} ",martin@… Active Tickets,211,South do not track new and removed permissions,commands,0.6-pre,1.0,enhancement,andrew,assigned,2009-07-22T12:44:44+01:00,2013-02-12T12:15:27Z,"Custom permissions can be added by specifying a permission tuple in models's Meta class. Adding a permission during a development is a one of the elemements that shall be tracked by south.",janusz.harkot@… Active Tickets,222,"When running forwards and backwards migrations, raise an exception if someone uses a non-FakeORM model",migrations,0.6-pre,1.0,enhancement,andrew,assigned,2009-07-31T03:25:54+01:00,2010-08-13T14:54:53+01:00,"Sometimes, people may import a Model directly in a ```forwards()``` or ```backwards()``` migration. This is a bad idea, because it works around the ORM. We can warn against this if we monkey-patch every ```models.get_models()``` so that ```__getattribute__()``` raises a ```NativeModelError```. This can be caught by ```run_forwards()``` and ```run_backwards()``` to let the developer know which migration was at fault.",sfllaw@… Active Tickets,366,Automatically create 3 migrations for changes which include data,migrations,0.6.2,1.0,enhancement,andrew,assigned,2010-03-02T09:05:40Z,2011-06-10T02:13:56+01:00,"When changing the schema, the docs recommend creating 3 migrations: * schema change (add columns) * data change * schema change (delete columns and/or tighten column constraints) This can come from a column rename or tightening data constraints (changing a column to null=False ) It would be nice if the --auto flag recognized that a model change could potentially affect existing data and create the three migrations (and the correct fake ORMs) needed for each step. Then the user simply needs to fill out the data migration part. ",pauloswald@… Active Tickets,430,"Avoiding the ""./manage.py migrate myapp 0001 --fake""",migrations,mercurial,1.0,enhancement,andrew,reopened,2010-04-19T01:44:28+01:00,2011-12-21T10:31:06Z,"It would be great if one could avoid having to run ""./manage.py migrate myapp 0001 --fake"" as described [http://south.aeracode.org/docs/convertinganapp.html here]. Please tell me if what I suggest is stupid, but would it not be possible to have a settings parameter that enabled the following extra functionallety in ""./mange.py migrate myapp"" (pseudo code): def migrate(“app”) “””Call after manage.py syncdb””” table_name = get_fist_table_name_from_migration_0001(app) table_list = get_list_of_table_names_from_db() if table_name in table_list and app not in south's_app_table: system(“./manage.py migrate myapp 0001 --fake”) Do you think it will work, ot am I missing something? If it does work, one could easily start out with an app that doesn't use South, and once there is a need to migrate it, just after a bunch of users has already started using the app, you can add South, push your upgrade to the community. And they would never notice a thing.",smyrman Active Tickets,639,Support fixture schema migrations,commands,unknown,1.0,enhancement,andrew,assigned,2010-10-27T22:17:14+01:00,2010-10-27T22:22:35+01:00,"I use fixtures for testing. But as my schema changes over time and I update the tests, there's no easy way to also update the fixtures. It would be amazing if South were able to schema migrate a fixture from one version of the schema to another.",robhudson Active Tickets,667,Migrations files doesn't pass pep8 and pyflake.,migrations,unknown,1.0,enhancement,andrew,assigned,2010-11-02T01:01:38Z,2011-03-08T22:42:56Z,"Hi, The automatic scripts created in migration doesn't pass the pep8 and pyflake test, and that it is really annoying if I use an automatic tool that checks for this in my scm. It should be great to create these files according pep8. It can be reproduced easily creating an initial migrations and run: pep8 0001_initial.py pyflake 0001_initial.py Best Regards.",jorgeecardona@… Active Tickets,829,"Add ""How to reset migrations"" to documentation",documentation,0.7.3,1.0,enhancement,andrew,assigned,2011-08-10T10:35:26+01:00,2011-08-10T10:44:04+01:00,"I'd like to suggest you add this answer to the documentation. http://groups.google.com/group/south-users/browse_thread/thread/888413f195acd9c2/0ee513da38240e19 or http://stackoverflow.com/questions/4625712/whats-the-recommended-approach-to-resetting-migration-history-using-django-south",rachel@… Active Tickets,32,ContentType table is not updated when renaming table,migrations,0.6-pre,The Future,defect,andrew,accepted,2008-10-21T14:05:47+01:00,2009-11-07T16:56:34Z,"When a table is renamed, the ContentType table is not updated, causing existing generic relations to fail. ",e.t.j.scheffers@… Active Tickets,87,migrating models from an abstract model class,commands,,The Future,defect,andrew,accepted,2009-02-27T04:46:45Z,2011-10-08T08:27:01+01:00,"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?",Antonius Common Active Tickets,520,models defined in tests are not created by South,migrations,0.7.1,The Future,defect,andrew,assigned,2010-08-02T10:28:59+01:00,2011-06-02T06:33:15+01:00,"Sometimes you want to test a new model in your unit tests. With Django, models defined in tests.py are created automatically (they are created by the regular syncdb when running the test command). {{{ from django.test import TestCase from django.db import models from myproject.myapp.models import MyAbstractBaseModel class MyTestModel(MyAbstractBaseModel): name = models.CharField(blank=False, max_length=100) class Meta: app_label = 'myapp' class SimpleTests(TestCase): def test_my_test_model(self): MyTestModel.objects.all() }}} These models in tests.py usually need an app_label of an existing application to be picked up. However, when the application is under South, these test models are skipped by Django and not picked up by South either. A simple work around for now is to set the app_label to use an application that is not under South, unless the app_label is actually important for your tests.",joeri@… Active Tickets,725,alter_column unconditionally drops check constraints,databaseapi,unknown,The Future,defect,andrew,assigned,2011-02-23T09:55:19Z,2011-02-23T18:09:41Z,"Just what the title says. The code has TODO: comments about it, and the !SqlServer backend issues warnings. Note that this is a very hard problem: At the database API level, often there isn't enough information to know if a constraint should be kept or dropped. Even when the information is available, extracting it is non-trivial. Anyway, it's a problem.",shai@… Active Tickets,777,SOUTH_DATABASE_ADAPTERS ignored,databaseapi,0.7.3,The Future,defect,andrew,new,2011-05-30T06:20:37+01:00,2011-12-09T11:50:43Z,"I have a Django application called Chorus. It uses a custom backend extended from the mysql backend in Django. The following addition to settings_local.py causes the following error: SOUTH_DATABASE_ADAPTERS = { 'chorus.database.backends.mysql': 'south.db.mysql' } Error: ""There is no South database module 'south.db.None' for your database. Please either choose a supported database, check for SOUTH_DATABASE_ADAPTER[s] settings, or remove South from INSTALLED_APPS."" My work around is to use the following addition to settings_local.py instead. It works OK for me, but if not mistaken it also means south won't support multiple django databases. Plus it would be nice if the requirements of using the 'default' key was documented somewhere. SOUTH_DATABASE_ADAPTERS = { 'default':'south.db.mysql' }",dave.trindall@… Active Tickets,779,GeoDjango data migrations appear to not respect objects = models.GeoManager(),migrations,0.7.3,The Future,defect,andrew,assigned,2011-05-30T21:21:42+01:00,2013-03-12T13:11:15Z,"Writing a data migration for GeoDjango, I attempted to use orm.ModelName.objects.get_or_create(coordinates=new_coordinates), but ran into the following error: {{{#!python class Migration(DataMigration): def forwards(self, orm): for area_code in orm.AreaCode.objects.all(): exchange, created = orm.Exchange.objects.get_or_create(coordinates=area_code.coordinates) area_code.exchange = exchange area_code.save() def backwards(self, orm): orm.Exchange.objects.all().delete() models = { ... } }}} {{{#!python Running migrations for area_codes: - Migrating forwards to 0004_refactor_to_exchanges. > area_codes:0004_refactor_to_exchanges Traceback (most recent call last): File ""./manage.py"", line 11, in execute_manager(settings) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 99, in run return self.run_migration(migration) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/Users/griff/code/envs/bbs/fidonet/area_codes/migrations/0004_refactor_to_exchanges.py"", line 11, in forwards exchange, created = orm.Exchange.objects.get_or_create(coordinates=area_code.coordinates) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/manager.py"", line 135, in get_or_create return self.get_query_set().get_or_create(**kwargs) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/query.py"", line 366, in get_or_create return self.get(**kwargs), False File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/query.py"", line 336, in get num = len(clone) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/query.py"", line 81, in __len__ self._result_cache = list(self.iterator()) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/query.py"", line 269, in iterator for row in compiler.results_iter(): File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/compiler.py"", line 672, in results_iter for rows in self.execute_sql(MULTI): File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/compiler.py"", line 717, in execute_sql sql, params = self.as_sql() File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/compiler.py"", line 65, in as_sql where, w_params = self.query.where.as_sql(qn=qn, connection=self.connection) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/where.py"", line 91, in as_sql sql, params = child.as_sql(qn=qn, connection=connection) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/where.py"", line 94, in as_sql sql, params = self.make_atom(child, qn, connection) File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/db/models/sql/where.py"", line 165, in make_atom if (len(params) == 1 and params[0] == '' and lookup_type == 'exact' File ""/Users/griff/code/envs/bbs/lib/python2.6/site-packages/django/contrib/gis/db/backends/postgis/adapter.py"", line 24, in __eq__ return (self.ewkb == other.ewkb) and (self.srid == other.srid) AttributeError: 'str' object has no attribute 'ewkb' }}} This appears to be related to http://groups.google.com/group/geodjango/browse_thread/thread/11a3016a0aeceec9/c563197b7fcb7ed6?lnk=gst&q=ewkb#c563197b7fcb7ed6 which indicates that get_or_create won't work without a GeoManager(). Since manager information is not saved in South's model freezing, it's not surprising this doesn't work. This is a very geodjango specific problem. BTW andrew, amazing project as always. I may cite you in my DPhil :P. Hope you're well.",griffith.rees@… Active Tickets,802,Models not found while creating initial,migrations,unknown,The Future,defect,andrew,infoneeded,2011-07-09T20:44:56+01:00,2011-07-09T23:03:43+01:00,"Hi! A have an application 'foo.bar'. So when I'm trying to create initial schemamigration: ./manage.py schemamigration foo.bar --initial I'm getting an empty initial migration. If I retry it says that there is no changes. It's obvious to me that south unable to find my foo.bar.models.",germanilyin@… Active Tickets,1073,South does not notice when a ForeignKey's type should change,commands,unknown,The Future,defect,andrew,accepted,2012-05-04T15:52:04+01:00,2012-05-04T16:03:11+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.",anonymous Active Tickets,1080,support for django-jython and postgresql,commands,unknown,The Future,defect,andrew,new,2012-05-16T19:46:24+01:00,2012-05-17T00:16:34+01:00,"As far as I can tell, South doesn't work with django-jython because it can't find any database adapters. Augmenting engine_modules with 'doj.backends.zxjdbc.postgresql': 'postgresql_psycopg2' seems to improve the situation and at least get it successfully talking to the database.",anonymous Active Tickets,173,South_migrationhistory needs status - when migrate fails in the middle,migrations,0.6-pre,The Future,enhancement,andrew,assigned,2009-06-04T23:15:09+01:00,2010-12-01T01:08:04Z,"Scenario: - migration 0004 is next to be runned - 0004 - 1st case - migration have some changes where commit has to be done inside of migration (commit/start transaction). - 0004 - 2nd case - some changes are outside of transaction management, i.e. can't be rolled back - as I know mysql DDL sql statements can't be rolled back - e.g. add column Migration process - failure in the middle of migration: - manage migrate 0004 - inside of migration commit is done, changes to db are saved permanently (1st case) and/or some things are out of db trans.management (2nd case) - migration fails - south rolls back - south_migrationhistory db is not changed (no new record) Recovery procedure: - south migration --list -> shows that 0004 is not done, but we have some changes to db saved - we try to start migration again - and 0004 will have wrong preassumption that everything is in the state of the end of 0003 migration, so migration can halt and/or lead to some inconsistent state Improvement suggestion: - add new char field status (cbo with predefined values) to south_migrationhistory table - south migration 0004 starts - insert new record in south_mighist table - status = STARTED (migration started) - case south finishes migration without error: update status=OK - case exception/failure in south migration: update status=ERR - manage migrate --list -> should show which migrations went ok and which failed (!=OK) - manage migrate -> should check that there is no !=OK statuses and only in this case migration can be started - fixing !=OK migrations - fix it manually back or forth. Then update south_mighistory with OK if forth, or reset it back if back (delete entry). for OK there is --fake 0004, and for reset call --fake 0003 which will mark 0004 not migrated Additional note: how to fix things up when migration is half done and half not - I think, should be done only manually - we have to see which changes are done and which not. That's why it is important to have some kind of log of all actions executed and saved - then choose direction - revert everything or finish to the end - and then one by one - whether revert or execute next to the end ",Robert Active Tickets,175,New DatabaseOperations commands backup/restore,commands,0.6-pre,The Future,enhancement,andrew,assigned,2009-06-09T11:27:12+01:00,2010-03-20T06:39:20Z,"Ticket #173 is dealing with failed migrations issues, how to detect etc. This ticket proposes one of the solutions how to solve ""unrevertable"" failed migrations with the help of system (and improve the system). First I would list some general rules I found useful when doing migrations: - migration development - develop and test on small data, do full test on test before deployment to production - migrating production - DO BACKUP, overview what is to be done, avoid live migrations, migrations/end user change conflict, control the process, reserve enough time for RESTORING in case of failure, test if migration is done correctly Relating to this I think that south should have at least two new commands: BACKUP/RESTORE commands in (can be part of !DatabaseOperations class). Such commands can help in solving conflicting state - like explained as CONFL (http://south.aeracode.org/ticket/173#comment:2). Full backup: - each database engine has its own backup/restore procedure - full database backup/restore on bigger db can last very long/big - full db bak/rest can be paused/blocked with record locks when doing it on live system and can cause conflicting states That's why I would suggest following: - do backup only on data that is to be changed - partial backup/restore (on ibm db2 export/import/load are used for such purposes) - request write lock on data that is to be backuped/changed/restored (maybe new !DatabaseOperations command - '''lock table'''? new ticket?) There could be two ways to do backup: - native db engine backup/restore commands - these have advantages like speed, add metadata, stability etc. - db engine agnostic backup/restore commands have advantages like independent data format, data can be transfered between diff db engines etc. == Implementation == I suggest following: - backup - use db engine agnostic backup - i.e. adjust logic used in [http://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata ""django-admin dumpdata""] for backup, and [http://docs.djangoproject.com/en/dev/ref/django-admin/#loaddata-fixture-fixture ""django-admin loaddata""] for restore - add !DatabaseOperations.backup(backup_name, queryset) which saves __.json in some predefined directory. Queryset param will be explained later - add additional output to migrate --list - which lists all backups that are in directory for each migration - add !DatabaseOperations.restore(backup_name) which loads __.json to database back Method backup has param queryset, which should enable partial backup. Queryset is django.queryset object with optional definition of list of columns to be backuped (i.e. ''exported''). Note that primary key must be allways included. Example: - I want to migrate model Person : column name -> first_name, last_name. Therefore I want to do backup table Person before actual migration - I can do backup in two ways: - the whole Person table with Person model definition - for '''full table backup''' - only Person.id (pk), person.name, person.first_name, person.last_name - '''column table backup''' - restore can be done in two ways: - from full table backup - the whole table is erased - recreated and loaded again - from column table backup - one by one record is updated by primary key - it updates only columns backuped (name, first_name, last_name). This kind of restore doesn't handle alter table commands. In '''column table''' restore there is an issue with eventual with new records added to table. Restore procedure should put db to the same state where it was before the backup. That means that new records in this limited backup mode should be deleted in restore procedure. How to detect them? We have list of id-s to be updated, all records that are not updated (pk not in pk_backuped_list) should be deleted. What with very large backups - how to avoid transaction overload. When you want to do update on 1.000.000 records then probably this can't be done in one transaction. That is why restore needs to do commit from time to time (db2 import has commitcount option). This should be optional parameter in restore procedure. I think that restore should be callable from shell too (e.g. ''migrate --restore'' or just ''restore''). My first impression is that this issue can become very complex, but if this is to be implemented, then I suggest for the first release to be implemented as simple as possible, but stable. ",Robert Active Tickets,370,Extended MultiDB Support,commands,0.7-pre,The Future,enhancement,andrew,assigned,2010-03-04T22:40:11Z,2011-11-14T07:09:19Z,"Implement more sophisticated support for MultiDB. This will be support for having different sets of migrations - one per database, usually - with different models, etc. in them. --auto will detect which models go where, by using the database router's allow_syncdb function, which Django already has, and do things roughly correctly.",andrew Active Tickets,484,Support custom typecasting when altering column (using()),databaseapi,0.7.1,The Future,enhancement,andrew,assigned,2010-06-22T22:13:13+01:00,2013-06-12T10:35:26+01:00,"When doing the following: db.alter_column('model_name', 'former_charfield', self.gf('django.db.models.fields.IntegerField')(unique=True)) This error is thrown by Postgres: django.db.utils.DatabaseError: column ""former_charfield"" cannot be cast to type integer Postgres supports a using() method for ALTER TABLE - that might be a solution? ",adam@… Active Tickets,580,Converting from abstract class inheritance to multi-table inheritance,commands,unknown,The Future,enhancement,andrew,accepted,2010-09-14T14:54:55+01:00,2010-09-14T17:19:47+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).,karimn2.0@… Active Tickets,792,Error starting a new Django project (windows7 - 32bit): south not synced,commands,0.7.3,,defect,andrew,assigned,2011-06-23T18:50:29+01:00,2012-11-08T19:12:35Z,"- Start new django project - install south in settings file and config the sqlite3 db - but when I syncdb, it says ""not synced: south"", I have checked the table is not created. Syncing... Creating tables ... Creating table auth_permission Creating table auth_group_permissions Creating table auth_group Creating table auth_user_user_permissions Creating table auth_user_groups Creating table auth_user Creating table auth_message Creating table django_content_type Creating table django_session Creating table django_site You just installed Django's auth system.. [etc etc] Superuser created successfully. Installing custom SQL ... Installing indexes ... No fixtures found. Synced: > django.contrib.auth > django.contrib.contenttypes > django.contrib.sessions > django.contrib.sites > django.contrib.messages > django.contrib.staticfiles Not synced (use migrations): - south (use ./manage.py migrate to migrate these)",gabriele@… Active Tickets,954,NoMigrations exception (even with --delete-ghost-migrations),commands,unknown,,defect,andrew,infoneeded,2011-11-16T08:30:05Z,2011-11-16T10:03:03Z,"command ./manage.py migrate --delete-ghost-migrations raises exception south.exceptions.NoMigrations (using south 0.7.3) - full traceback http://pastebin.com/jvUyfU3C How to reproduce: create app with some migrations, apply them to database, then delete ""migrations"" folder from this app (not removing migrations from database). Then run this command. I expected that it should delete non-existant migrations. Maybe similar to http://south.aeracode.org/ticket/354 - but it is marked as fixed in 0.7",kostia.lopuhin@… Active Tickets,986,Unsupported db backend results in wrong error message,commands,unknown,,defect,andrew,new,2012-01-10T20:09:31Z,2012-01-10T20:09:31Z,"I don't have all the details on the setup, but a fellow asked on #django-south about trouble using django-mongodb (in a multi-db setup, of course) with South. I don't think there's anything to be done for him until someone fixes up a mongodb backend for South, but while looking for the root cause I spent some time in db/__init__.py, and I think there's some refactoring gone awry (I'll quote from current head, but it's unchanged since 0.7.3 anyway). The message reported was ""There is no South database module 'south.db.None' for your database ..."" which is issued from the failure case in the loop at lines 59-61. My first hint that something was wrong was the comment suggesting that this wasn't supposed to fail except in 1.1 (pre-multidb). Looking up above to the 1.2 branch of the setup code, it appears that db_engines is now setup using the string name of the South module (35-41, esp 37), but the sanity checking code that follows is checking for None... which of course never matches 'south.db.None' at line 44... and that's the obvious fix, of course. ",martin maney Active Tickets,1066,Custom field specified by model with the full application label problem,migrations,0.7.3,,defect,andrew,new,2012-04-17T14:05:19+01:00,2012-04-17T14:05:19+01:00,"Hi, I run into a problem when using a Custom field and the custom field uses a string as the reference. I created a demo of the problem here: https://bitbucket.org/alien8/north Please also see the last 2 commits. It shows the change that breaks it. South version is 0.7.4, Django is 1.4, Python is 2.7.1. I tested on Mac OS X and Ubuntu 11.10. Thanks for looking into this issue. Thanks for South! It's great! Frank ",fb@… Active Tickets,1189,Migration.gf should be a classmethod,databaseapi,0.7.6,,defect,andrew,reopened,2012-11-17T01:17:25Z,2012-11-19T22:47:05Z,"As the title says, `BaseMigration.gf` should be a classmethod. My usecase: I created a field that takes a class type as its only argument, so when I was writing the introspection rules for it I need to write something like: {{{#!python def enum_converter(value): if issubclass(value, Enum): return 'Migration().gf(""{}.{}"")'.format(value.__module__, value.__name__) raise ValueError(""Unknown value type `{!r}` for enum argument"".format(value)) add_introspection_rules( [ ( [EnumField], # Field Name [], # Args { # kwargs 'enum' : ['enum', {'converter' : enum_converter, 'is_django_function' : True}], } ) ], ['^project\.fields\.enumfield\.EnumField'] ) }}} As you can see `Migration().gf(""{}.{}"")` is not really what I want to do, I would rather to Migration.gf(). Ideally the `ask_for_it_by_name` function should be available in the eval context, but that's another matter. Thanks, Richard.",reames@… Active Tickets,1234,KeyError on importing south.db if settings.DATABASES contains only Django dummy database,databaseapi,mercurial,,defect,andrew,new,2013-03-21T14:56:18Z,2013-03-21T14:59:33Z,"I have a Django settings file that I use for pure unit tests. It has no DATABASES configured. At runtime, Django uses a default dummy database. When the unit tests load the south app, Django imports south.models, which imports south.db. The latter raises KeyError on the final statement in south/db/__init__.py. I'm using South 0.7.5. The relevant code looks the same on the tip in Mercurial. Here's a workaround for comment: https://bitbucket.org/matthewlmcclure/south/commits/ec097d53590fdc982e38639a6f45c043a7842ce3",matthewlmcclure@… Active Tickets,1252,OverflowError for DateFields with Default date.min/date.max,commands,0.7.6,,defect,andrew,assigned,2013-05-10T03:03:44+01:00,2013-05-10T19:08:12+01:00,"I have a model with two fields, one with a default value date.min and another with a default value of date.max: min_date = models.DateField(default=date.min) max_date = models.DateField(default=date.max) When I generate migrations involving this model, Migration.models ends up with cases like: 'min_date': ('django.db.models.fields.DateField', [], {'default': 'datetime.datetime(9999, 12, 31, 0, 0)'}), 'max_date': ('django.db.models.fields.DateField', [], {'default': 'datetime.datetime(1, 1, 1, 0, 0)'}) Attempting to migrate leads to an overflow error: OverflowError: date value out of range Inspecting the code, this appears to be due to timezone resolution issues. Changing the lines above to: 'min_date': ('django.db.models.fields.DateField', [], {'default': 'datetime.date(9999, 12, 31)'}), 'max_date': ('django.db.models.fields.DateField', [], {'default': 'datetime.date(1, 1, 1)'}) Fixes the problem. I'm not arguing against timezone-awareness in general, and I understand the need to deal with offsets when converting from datetime to date. Nevertheless, going from a pre-specified date to a datetime to a DateField seems like it introduces an artificial error in this case.",anonymous Active Tickets,970,Oracle backend,databaseapi,0.7.3,,enhancement,andrew,new,2011-12-09T15:16:41Z,2012-01-20T17:23:38Z,"I've created an oracle backend for myself, and I thought it might be useful to others.",cyoungblood@… Active Tickets,1010,Addition for Fixtures Docs,documentation,0.7.3,,enhancement,andrew,new,2012-01-23T07:25:01Z,2012-01-23T07:25:01Z,Further explanation of problems loading fixtures from json in data migrations if schema changes are made.,Andrew Macgregor Active Tickets,1013,Access GenericForeignKey in datamigration,documentation,0.7.3,,enhancement,andrew,new,2012-01-24T10:47:09Z,2012-01-24T10:47:09Z,"I found the [http://south.aeracode.org/docs/generics.html](the docs) very vague about how to work with GenericForeignKeys while doing (data)migrations. I tried a lot of variations of the code in the manual, but found all of them failing. The final working solution was rather simple: {{{ subject_type = orm[""%s.%s"" % (act.subject_type.app_label, act.subject_type.model)] act.subject = subject_type.objects.get(pk=act.subject_id) }}} Here `act` has a generic relation through the attribute `subject`. It circumvents the use of ContentType directly and uses the frozen orm as provided by south. I think other users could benefit from a reference to such a solution when working with migrating GenericForeignKeys.",bouke@… Active Tickets,1055,"Warning in migration template: ""use orm['fooapp.YourModel'] not from fooapp.models import YourModel",commands,unknown,,enhancement,andrew,new,2012-03-26T09:14:11+01:00,2012-03-27T15:22:03+01:00,"I know it and you know it. But many don't: {{{ use orm['fooapp.YourModel'] not 'from fooapp.models import YourModel' in migrations }}} Please add this warning to the created migration templates. Since it is just line, I think you don't need a patch.",guettli Active Tickets,1217,Add support for index_together,migrations,mercurial,,enhancement,andrew,new,2013-02-17T21:27:58Z,2013-04-29T00:37:14+01:00,"Django 1.5 adds a Meta option [https://docs.djangoproject.com/en/dev/ref/models/options/#django.db.models.Options.index_together index_together] to specify non-unique multicolumn indexes. South already has the database api support for these via db.create_index and db.delete_index. index_together needs be added to the list of Meta attributes that are frozen, and hooked up to the correct db.create/delete_index calls.",Mike Fogel Active Tickets,393,South executes unnecessary SQL when adding a field,migrations,0.7-rc1,0.7,defect,andrew,reopened,2010-03-23T14:30:49Z,2011-03-01T10:03:02Z,"South (appears to?) execute unnecessary SQL when adding new fields: it issues an `ALTER COLUMN ... TYPE` command that isn't needed. This is under PostgreSQL/psycopg2. To reproduce, start with this model: {{{ class Person(models.Model): pass }}} Create an apply an initial migration, then add a field: {{{ class Person(models.Model): name = models.CharField(max_length=200, default="""") }}} Create a migration for the `name` field, then run `migrate -v2`: {{{ - Soft matched migration 0002 to 0002_add_person_name_field. Running migrations for people: - Migrating forwards to 0002_add_person_name_field. > people:0002_add_person_name_field = ALTER TABLE ""people_person"" ADD COLUMN ""name"" varchar(200) NOT NULL DEFAULT ''; [] = ALTER TABLE ""people_person"" ALTER COLUMN ""name"" TYPE varchar(200), ALTER COLUMN ""name"" DROP DEFAULT, ALTER COLUMN ""name"" SET NOT NULL; [] }}} Note the second `ALTER COLUMN ... TYPE` command. I doubt that this is dangerous, but it is unnecessary, and on databases under load it could make migrations take longer (since `ALTER TYPE` requires an exclusive lock).",jacob@… Active Tickets,178,Add logging to db commands (and possibly ORM),databaseapi,0.6-pre,1.0,defect,andrew,assigned,2009-06-16T23:03:16+01:00,2011-06-22T00:48:50+01:00,"Suggested by #176 initially; all SQL from db commands should be logged to a text file, possibly capturing ORM ones too if possible.",andrew Active Tickets,526,add-model doesn't create m2m tables,commands,0.7.1,1.0,defect,andrew,assigned,2010-08-13T15:21:49+01:00,2011-01-25T08:32:37Z,"The add-model command doesn't add m2m tables, however, the auto command does add m2m tables so no massive issue. Apart from the fact I've just wasted a few hours!",spenoir Active Tickets,533,Renaming a table should also rename unique constraints,databaseapi,unknown,1.0,defect,andrew,assigned,2010-08-17T04:27:26+01:00,2010-12-01T20:31:07Z,"Once a project has built up a South migration history a table rename can be confusing for developers. You may get a django error page that says: Exception Type: IntegrityError Exception Value: duplicate key value violates unique constraint ""oldtablename_userprofile_user_id_key"" This will be hard to debug because the oldtablename may not be in the current schema. The implementation of rename_table doesn't appear to drop/recreate constraints with the new table name.",pauloswald@… Active Tickets,573,South fails to migrate on custom field AutoNow whcih extends Datetime field,migrations,unknown,1.0,defect,andrew,assigned,2010-09-02T11:18:14+01:00,2012-06-06T15:45:55+01:00," - Migrating forwards to 0001_initial. > milestones:0001_initial Traceback (most recent call last): File ""manage.py"", line 11, in execute_manager(settings) File ""/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/core/management/__init__.py"", line 362, in execute_manager utility.execute() File ""/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/core/management/__init__.py"", line 303, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/core/management/base.py"", line 195, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/core/management/base.py"", line 222, in execute output = self.handle(*args, **options) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/management/commands/migrate.py"", line 105, in handle ignore_ghosts = ignore_ghosts, File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/__init__.py"", line 191, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/migrators.py"", line 221, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/migrators.py"", line 292, in migrate_many result = self.migrate(migration, database) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/migrators.py"", line 125, in migrate result = self.run(migration) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/migrators.py"", line 93, in run south.db.db.current_orm = self.orm(migration) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/migrators.py"", line 246, in orm return migration.orm() File ""/setup/trunk/sspl/src/ssplsite/../shared/south/utils.py"", line 62, in method value = function(self) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/migration/base.py"", line 422, in orm return FakeORM(self.migration_class(), self.app_label()) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/orm.py"", line 46, in FakeORM _orm_cache[args] = _FakeORM(*args) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/orm.py"", line 125, in __init__ self.models[name] = self.make_model(app_label, model_name, data) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/orm.py"", line 318, in make_model field = self.eval_in_context(code, app, extra_imports) File ""/setup/trunk/sspl/src/ssplsite/../shared/south/orm.py"", line 236, in eval_in_context return eval(code, globals(), fake_locals) File """", line 1 SouthFieldClass(default=datetime.datetime(2010, 8, 31, 4, 23, 35, 884429, tzinfo=)) ^ SyntaxError: invalid syntax ",dextrous85@… Active Tickets,579,Field name not updated on ManyToMany through table,migrations,0.7.2,1.0,defect,andrew,accepted,2010-09-13T02:09:07+01:00,2010-12-01T19:56:28Z,"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!",thomas.paul.matthews@… Active Tickets,596,South emits signals which do not honor Django's expectations.,migrations,0.7.2,1.0,defect,andrew,infoneeded,2010-10-04T13:10:11+01:00,2010-10-06T10:38:30+01:00,"During unit testing for any project with South installed, Model signals (such as post_delete) are being issued by South with ''MigrationHistory'' as the ''sender''. It appears that the ''sender'' does not satisfy all of Django's expectations. Specifically, it is not possible to load the ''ContentType'' of the ''sender'', as the following code: {{{ ContentType.objects.get_for_model(sender) }}} will result in the following exception: {{{ ... ContentType.objects.get_for_model(sender) ... File "".../django/contrib/contenttypes/models.py"", line 40, in get_for_model self._add_to_cache(self.db, ct) File "".../django/contrib/contenttypes/models.py"", line 70, in _add_to_cache key = (model._meta.app_label, model._meta.object_name.lower()) AttributeError: 'NoneType' object has no attribute '_meta' }}} A workaround is to check at the signal listener whether the ''sender'' of a signal is ''MigrationHistory'' and ignore the signal, however, this is ad-hoc and creates an explicit South dependency.",Alexis Petrounias Active Tickets,690,When changing a FK that had no default and using default datetime.datetime.today() getting syntax error,migrations,mercurial,1.0,defect,andrew,infoneeded,2010-12-15T22:04:19Z,2010-12-29T12:00:29Z,"Here's the error: Traceback (most recent call last): File ""manage.py"", line 11, in execute_manager(settings) File ""/Users/davemerwin/.virtualenvs/sprout/lib/python2.6/site-packages/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/Users/davemerwin/.virtualenvs/sprout/lib/python2.6/site-packages/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/Users/davemerwin/.virtualenvs/sprout/lib/python2.6/site-packages/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/Users/davemerwin/.virtualenvs/sprout/lib/python2.6/site-packages/django/core/management/base.py"", line 220, in execute output = self.handle(*args, **options) File ""/Users/davemerwin/.virtualenvs/sprout/src/south/south/management/commands/schemamigration.py"", line 83, in handle if migrations.app_label() not in getattr(last_migration.migration_class(), ""complete_apps"", []): File ""/Users/davemerwin/.virtualenvs/sprout/src/south/south/migration/base.py"", line 307, in migration_class return self.migration().Migration File ""/Users/davemerwin/.virtualenvs/sprout/src/south/south/utils.py"", line 62, in method value = function(self) File ""/Users/davemerwin/.virtualenvs/sprout/src/south/south/migration/base.py"", line 298, in migration raise exceptions.BrokenMigration(self, sys.exc_info()) south.exceptions.BrokenMigration: While loading migration 'forest:0006_auto__chg_field_leaf_status__chg_field_leaf_impact': Traceback (most recent call last): File ""/Users/davemerwin/.virtualenvs/sprout/src/south/south/migration/base.py"", line 294, in migration migration = __import__(full_name, {}, {}, ['Migration']) File ""/Users/davemerwin/sandbox/sprout/sprout/forest/migrations/0006_auto__chg_field_leaf_status__chg_field_leaf_impact.py"", line 21 db.alter_column('forest_leaf', 'status_id', self.gf('django.db.models.fields.related.ForeignKey')(default=, to=orm['forest.Status'])) ^ SyntaxError: invalid syntax ",dave@… Active Tickets,697,MySQL rename column and table fails when present in a foreign key,databaseapi,0.7,1.0,defect,andrew,assigned,2011-01-01T02:31:00Z,2011-11-25T05:53:52Z,"MySQL (or south) fails to manage foreign key mappings when renaming either columns or tables. I found this occuring on south 0.7, against the following mysql mysql Ver 14.12 Distrib 5.0.51b, for Win32 (ia32) I will attach a (debug/working) fix for this (I'll provide a proper diff with better code at a later point)",s_dalton@… Active Tickets,741,CharField false change detection (Null attribute),migrations,0.7.3,1.0,defect,andrew,assigned,2011-03-17T20:49:09Z,2011-03-25T10:36:02Z,"We have a model with CharField fields without null attribute (Django default appĺies: false) i.e. {{{ foo = models.CharField(max_length=250) }}} Our initial migration shows {{{ db.create_table(... (...), ('foo', self.gf('django.db.models.fields.CharField')(max_length=250)), )) }}} We changed models.py without affecting field definitions. The next migration create lines like this {{{ db.alter_column('fooapp_footable', 'foo', self.gf('django.db.models.fields.CharField')(max_length=250, null=True)) }}} The same happen to all the CharFields. We expected to have no change at all (no migration file or an empty one), so this seems to be a bug. Also, when the migration is applied, the database remains unchanged. We have: - PostgreSQL 8.3 - Django 1.2.3 ",uti_sis@… Active Tickets,757,"South ""forgets"" indexes on SQLite3",migrations,0.7.3,1.0,defect,andrew,assigned,2011-04-12T17:14:52+01:00,2011-08-11T05:15:23+01:00,"I just noticed that South ""forgets"" indexes between migrations on SQLite3. The function south.db.sqlite3._remake_table does analyze existing indexes for unique entries and primary keys, but ignores any other indexes attached to the table. Basically, any column indexes that are not part of *current* migration get lost during the _remake_table run. Tested on trunk version of South. I can provide migration history with --verbosity=2 if needed.",Jirka.Vejrazka@… Active Tickets,760,Autoincrementing primary keys for sqlite3,databaseapi,0.7.3,1.0,defect,andrew,assigned,2011-04-20T08:45:30+01:00,2011-04-20T12:38:32+01:00,"Sqlite3 re-uses primary keys by default. If a row is deleted, the next one will use the same id. This is bad and AFAIK other dbms always increment the primary key by default. This can be fixed for sqlite3 by explicitely giving the autoincrement keyword for the primary key column.",Jonttu Active Tickets,795,Changing DateField.auto_now generates a redundant migration,commands,0.7.3,1.0,defect,andrew,assigned,2011-07-06T13:33:19+01:00,2011-07-06T14:53:23+01:00,"1. Change a DateTimeField like this: {{{#!python class Item(models.Model): # update_time = models.DateTimeField(null=True) update_time = models.DateTimeField(null=True, auto_now=True) }}} 2. Run `manage.py schemamigration gallery --auto` 3. The following migration is created: {{{#!python class Migration(SchemaMigration): def forwards(self, orm): # Changing field 'Item.update_time' db.alter_column('gallery_item', 'update_time', self.gf('django.db.models.fields.DateTimeField')(auto_now=True, null=True)) def backwards(self, orm): # Changing field 'Item.update_time' db.alter_column('gallery_item', 'update_time', self.gf('django.db.models.fields.DateTimeField')(null=True)) }}} 4. When this migration is run (either forward or backward!), the ''same'' query is executed which does nothing (at least, on PostgreSQL): {{{ ALTER TABLE ""gallery_item"" ALTER COLUMN ""update_time"" TYPE timestamp with time zone, ALTER COLUMN ""update_time"" DROP NOT NULL, ALTER COLUMN ""update_time"" DROP DEFAULT; }}} Expected: 3. No migration is created for this change, because it doesn't actually affect the database schema.",me@… Active Tickets,833,add_column with an autofield fails,commands,0.7.3,1.0,defect,andrew,assigned,2011-08-11T19:28:29+01:00,2011-08-12T14:07:27+01:00,"In the db.add_column() generated by manage.py schemamigration you get a default=0 or whatever you choose, but postgresql complains about multiple default values, probably because it's adding a SERIAL field which has an implicit default.",Terry Brown Active Tickets,946,ORM does not cascade deletion of rows across apps,commands,0.7.3,1.0,defect,andrew,new,2011-11-07T22:59:55Z,2011-11-07T23:24:53Z,"I'm using django south 0.7.3, and I'm running into the following error. I have django application A, with model Foo. I have django application B, with model Bar. Bar.foo is a foreign key pointing to an instance of Foo. I created a data migration which deletes some Foo objects. However, the migration fails with the error copied below. The behavior I expected is that deletion of a food object would result in a cascading delete of all bar objects which reference it. This is related to ticket #165, though I believe ticket #165 occurred when both Foo and Bar were contained in app A. {{{ Traceback (most recent call last): File ""manage.py"", line 11, in execute_manager(settings) File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/core/management/__init__.py"", line 438, in execute_manager utility.execute() File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/core/management/__init__.py"", line 379, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/core/management/base.py"", line 191, in run_from_argv self.execute(*args, **options.__dict__) File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/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 107, 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 222, 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 293, 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 126, 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 100, in run return self.run_migration(migration) File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/migration/migrators.py"", line 90, in run_migration south.db.db.commit_transaction() File ""/usr/local/lib/python2.6/dist-packages/South-0.7.3-py2.6.egg/south/db/generic.py"", line 854, in commit_transaction transaction.commit() File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/db/transaction.py"", line 142, in commit connection.commit() File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/db/backends/__init__.py"", line 201, in commit self._commit() File ""/usr/local/lib/python2.6/dist-packages/Django-1.3-py2.6.egg/django/db/backends/postgresql_psycopg2/base.py"", line 200, in _commit return self.connection.commit() django.db.utils.IntegrityError: update or delete on table ""a_foo"" violates foreign key constraint ""foo_id_refs_id_190d3aa60668023d"" on table ""b_bar"" DETAIL: Key (id)=(130820) is still referenced from table ""b__bar"". }}} ",stucchio@… Active Tickets,958,Django-south test management commands breaks ability to use Nose coverage options,commands,0.7.3,1.0,defect,andrew,accepted,2011-11-21T14:05:11Z,2013-04-24T21:49:25+01:00,"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) ",nicp@… Active Tickets,992,Primary Key: SlugField to CharField,migrations,unknown,1.0,defect,andrew,accepted,2012-01-13T11:45:03Z,2012-01-13T11:48:06Z,"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",guettli Active Tickets,1050,converstion of IntegerField to PositiveIntegerField has constraint problems,migrations,0.7.3,1.0,defect,andrew,accepted,2012-03-05T20:13:31Z,2012-03-05T22:10: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.",ctrudeau@… Active Tickets,1076,"MySQL: delete_unique() fails if the index ""supports"" a FK",migrations,0.7.5,1.0,defect,andrew,accepted,2012-05-09T20:39:13+01:00,2012-10-02T12:21:42+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. ",paul.dubois@… Active Tickets,1116,TypeError: cannot concatenate 'str' and 'int' objects,commands,0.7.5,1.0,defect,andrew,new,2012-06-12T03:57:20+01:00,2013-02-07T23:25:47Z,"While going through the tutorial (http://south.readthedocs.org/en/latest/tutorial/part1.html) and running the ""0002_auto__add_field_knight_dances_whenever_able"" migration I get the following error: {{{ File ""/tmp/South-0.7.5/south/db/sqlite3.py"", line 79, in _remake_table type += "" DEFAULT "" + column_info['dflt_value'] TypeError: cannot concatenate 'str' and 'int' objects }}} The column_info['dflt_value'] returns the int zero which should probably be converted to a str(). Full stack trace: {{{ $> python2.6 ./manage.py migrate southtut Running migrations for southtut: - Migrating forwards to 0002_auto__add_field_knight_dances_whenever_able. > southtut:0002_auto__add_field_knight_dances_whenever_able ! 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: ! The South developers regret this has happened, and would ! like to gently persuade you to consider a slightly ! easier-to-deal-with DBMS (one that supports DDL transactions) ! NOTE: The error which caused the migration to fail is further up. Error in migration: southtut:0002_auto__add_field_knight_dances_whenever_able Traceback (most recent call last): File ""./manage.py"", line 10, in execute_from_command_line(sys.argv) File ""/tmp/Django-1.4/django/core/management/__init__.py"", line 443, in execute_from_command_line utility.execute() File ""/tmp/Django-1.4/django/core/management/__init__.py"", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/tmp/Django-1.4/django/core/management/base.py"", line 196, in run_from_argv self.execute(*args, **options.__dict__) File ""/tmp/Django-1.4/django/core/management/base.py"", line 232, in execute output = self.handle(*args, **options) File ""/tmp/South-0.7.5/south/management/commands/migrate.py"", line 107, in handle ignore_ghosts = ignore_ghosts, File ""/tmp/South-0.7.5/south/migration/__init__.py"", line 219, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 235, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 310, in migrate_many result = self.migrate(migration, database) File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 133, in migrate result = self.run(migration) File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 107, in run return self.run_migration(migration) File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 81, in run_migration migration_function() File ""/tmp/South-0.7.5/south/migration/migrators.py"", line 57, in return (lambda: direction(orm)) File ""/gpfs/scratch05/data/tmp/portal/southtut/migrations/0002_auto__add_field_knight_dances_whenever_able.py"", line 14, in forwards keep_default=False) File ""/tmp/South-0.7.5/south/db/sqlite3.py"", line 31, in add_column field.column: self._column_sql_for_create(table_name, name, field, False), File ""/tmp/South-0.7.5/south/db/generic.py"", line 44, in _cache_clear return func(self, table, *args, **opts) File ""/tmp/South-0.7.5/south/db/sqlite3.py"", line 79, in _remake_table type += "" DEFAULT "" + column_info['dflt_value'] TypeError: cannot concatenate 'str' and 'int' objects }}}",anonymous Active Tickets,1160,field 'id' doesn't have a default value,migrations,0.7.6,1.0,defect,andrew,new,2012-08-20T14:13:04+01:00,2012-08-20T14:33:18+01:00,"If I alter a column to be an Autofield with MySQL, I'm receiving a warning if I try to insert a row in this table. I had to apply the solution below. http://webit.ca/2012/01/field-id-doesnt-have-a-default-value/ After looking more closely to query executed by South, it's because alter_column run a 'DROP DEFAULT'. eg: db.alter_column('table', 'id',self.gf('django.db.models.fields.AutoField')( primary_key=True)) Should put you in the situation I m happy to submit a patch which doesn't 'DROP DEFAULT' in case of AutoField and MySQL... but it sounds dirty and maybe not the right way. Or adding an argument to not call _alter_set_defaults Any suggestion ? ",rachid.belaid@… Active Tickets,1172,problem with sqlite3 migration when changing CharField to SlugField,commands,unknown,1.0,defect,andrew,new,2012-09-15T17:59:12+01:00,2013-02-09T16:38:40Z,"Running migrations on sqlite3 after I changed a model field from CharField to SlugField: {{{ DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': '/opt/class2go/celery/celerydb.sqlite', }, } }}} Got the following exception: {{{ Running migrations for c2g: - Migrating forwards to 0003_auto__chg_field_additionalpage_menu_slug__chg_field_additionalpage_slu. > c2g:0001_initial > c2g:0002_auto__add_courseemail > c2g:0003_auto__chg_field_additionalpage_menu_slug__chg_field_additionalpage_slu FATAL ERROR - The following SQL query failed: CREATE INDEX ""c2g_additional_pages_a951d5d6"" ON ""c2g_additional_pages"" (""slug""); The error was: index c2g_additional_pages_a951d5d6 already exists ! 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: = DROP INDEX ""c2g_additional_pages_a951d5d6"" [] = DROP INDEX ""c2g_additional_pages_c5a860f5"" [] ! The South developers regret this has happened, and would ! like to gently persuade you to consider a slightly ! easier-to-deal-with DBMS (one that supports DDL transactions) ! NOTE: The error which caused the migration to fail is further up. Error in migration: c2g:0003_auto__chg_field_additionalpage_menu_slug__chg_field_additionalpage_slu Traceback (most recent call last): File ""./manage.py"", line 10, in execute_from_command_line(sys.argv) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/core/management/__init__.py"", line 443, in execute_from_command_line utility.execute() File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/core/management/__init__.py"", line 382, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/core/management/base.py"", line 196, in run_from_argv self.execute(*args, **options.__dict__) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/core/management/base.py"", line 232, in execute output = self.handle(*args, **options) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/management/commands/migrate.py"", line 108, in handle ignore_ghosts = ignore_ghosts, File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/__init__.py"", line 213, in migrate_app success = migrator.migrate_many(target, workplan, database) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/migrators.py"", line 235, in migrate_many result = migrator.__class__.migrate_many(migrator, target, migrations, database) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/migrators.py"", line 310, in migrate_many result = self.migrate(migration, database) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/migrators.py"", line 133, in migrate result = self.run(migration) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/migrators.py"", line 107, in run return self.run_migration(migration) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/migration/migrators.py"", line 82, in run_migration south.db.db.execute_deferred_sql() File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/db/generic.py"", line 309, in execute_deferred_sql self.execute(sql) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/south/db/generic.py"", line 273, in execute cursor.execute(sql, params) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/db/backends/util.py"", line 40, in execute return self.cursor.execute(sql, params) File ""/Users/jbau/projects/class2go/main/venv_c2g/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py"", line 337, in execute return Database.Cursor.execute(self, query, params) django.db.utils.DatabaseError: index c2g_additional_pages_a951d5d6 already exists }}} These migrations run fine on mysql. And also, when I delete all of them and generate a single initial migration from the models, that migration runs fine on mysql and sqlite3",jbau@… Active Tickets,1176,GeoDjango geometry fields causes exception when using MySQL and InnoDB.,databaseapi,unknown,1.0,defect,andrew,new,2012-09-19T18:22:05+01:00,2012-09-19T18:31:32+01:00,"As topic says: If a migration that creates a table that contains geometry filed from GeoDjango, the migration throws an exception: {{{ django.db.utils.DatabaseError: (1464, ""The used table type doesn't support SPATIAL indexes"") }}} from the query {{{ CREATE SPATIAL INDEX `app_model_field_id` ON `app_model`(`field`); }}} This is since the database is configured to innodb. A solution would be to run {{{ ALTER TABLE app_model ENGINE=MyISAM; }}} so that that specific table uses MyISAM. This would have to be done after creating the table, but before the creation of spatial index. However, since both are done in one command within south there's no place to run it.",sebastian@… Active Tickets,1182,postgresql: Generic DB adds constraints on columns that do not exist,databaseapi,0.7,1.0,defect,andrew,new,2012-10-10T23:43:32+01:00,2012-10-11T08:58:06+01:00,"The generic db seems to be adding constraints to columns that do not exist. This is causing issues with postgresql, but is perfectly fine in mysql and sqlite3. Here's the generated sql that is incorrect (the column 'id' does not exist): {{{#!sql ALTER TABLE `oozie_workflow` ADD CONSTRAINT `start_id_refs_id_7a0f5ec1ee988a53` FOREIGN KEY (`start_id`) REFERENCES `oozie_start` (`id`) }}} Here is the migration that's causing the problem: {{{#!python # encoding: utf-8 import datetime from south.db import db from south.v2 import SchemaMigration from django.db import models class Migration(SchemaMigration): def forwards(self, orm): # Adding model 'Job' db.create_table('oozie_job', ( ('is_shared', self.gf('django.db.models.fields.BooleanField')(default=False, db_index=True, blank=True)), ('description', self.gf('django.db.models.fields.CharField')(max_length=1024, blank=True)), ('parameters', self.gf('django.db.models.fields.TextField')(default='[]')), ('deployment_dir', self.gf('django.db.models.fields.CharField')(max_length=1024, blank=True)), ('schema_version', self.gf('django.db.models.fields.CharField')(max_length=128)), ('last_modified', self.gf('django.db.models.fields.DateTimeField')(auto_now=True, db_index=True, blank=True)), ('owner', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['auth.User'])), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), )) db.send_create_signal('oozie', ['Job']) # Adding model 'Workflow' db.create_table('oozie_workflow', ( ('job_xml', self.gf('django.db.models.fields.CharField')(default='', max_length=512, blank=True)), ('end', self.gf('django.db.models.fields.related.ForeignKey')(blank=True, related_name='end_workflow', null=True, to=orm['oozie.End'])), ('is_single', self.gf('django.db.models.fields.BooleanField')(default=False, blank=True)), ('job_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Job'], unique=True, primary_key=True)), ('job_properties', self.gf('django.db.models.fields.TextField')(default='[]')), ('start', self.gf('django.db.models.fields.related.ForeignKey')(blank=True, related_name='start_workflow', null=True, to=orm['oozie.Start'])), )) db.send_create_signal('oozie', ['Workflow']) # Adding model 'Link' db.create_table('oozie_link', ( ('comment', self.gf('django.db.models.fields.CharField')(default='', max_length=1024, blank=True)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('parent', self.gf('django.db.models.fields.related.ForeignKey')(related_name='child_node', to=orm['oozie.Node'])), ('child', self.gf('django.db.models.fields.related.ForeignKey')(related_name='parent_node', to=orm['oozie.Node'])), )) db.send_create_signal('oozie', ['Link']) # Adding model 'Node' db.create_table('oozie_node', ( ('description', self.gf('django.db.models.fields.CharField')(default='', max_length=1024, blank=True)), ('workflow', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Workflow'])), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('node_type', self.gf('django.db.models.fields.CharField')(max_length=64)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), )) db.send_create_signal('oozie', ['Node']) # Adding model 'Mapreduce' db.create_table('oozie_mapreduce', ( ('files', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('job_xml', self.gf('django.db.models.fields.CharField')(default='', max_length=512, blank=True)), ('jar_path', self.gf('django.db.models.fields.CharField')(max_length=512)), ('job_properties', self.gf('django.db.models.fields.TextField')(default='[]')), ('archives', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True)), ('prepares', self.gf('django.db.models.fields.TextField')(default='[]')), )) db.send_create_signal('oozie', ['Mapreduce']) # Adding model 'Streaming' db.create_table('oozie_streaming', ( ('files', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('mapper', self.gf('django.db.models.fields.CharField')(max_length=512)), ('reducer', self.gf('django.db.models.fields.CharField')(max_length=512)), ('job_properties', self.gf('django.db.models.fields.TextField')(default='[{""name"":""oozie.use.system.libpath"",""value"":""true""}]')), ('archives', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), )) db.send_create_signal('oozie', ['Streaming']) # Adding model 'Java' db.create_table('oozie_java', ( ('files', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('job_xml', self.gf('django.db.models.fields.CharField')(default='', max_length=512, blank=True)), ('jar_path', self.gf('django.db.models.fields.CharField')(max_length=512)), ('java_opts', self.gf('django.db.models.fields.CharField')(max_length=256, blank=True)), ('args', self.gf('django.db.models.fields.CharField')(max_length=4096, blank=True)), ('job_properties', self.gf('django.db.models.fields.TextField')(default='[]')), ('prepares', self.gf('django.db.models.fields.TextField')(default='[]')), ('archives', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), ('main_class', self.gf('django.db.models.fields.CharField')(max_length=256)), )) db.send_create_signal('oozie', ['Java']) # Adding model 'Pig' db.create_table('oozie_pig', ( ('files', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('job_xml', self.gf('django.db.models.fields.CharField')(default='', max_length=512, blank=True)), ('job_properties', self.gf('django.db.models.fields.TextField')(default='[{""name"":""oozie.use.system.libpath"",""value"":""true""}]')), ('params', self.gf('django.db.models.fields.TextField')(default='[]')), ('archives', self.gf('django.db.models.fields.CharField')(default='[]', max_length=512)), ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), ('prepares', self.gf('django.db.models.fields.TextField')(default='[]')), ('script_path', self.gf('django.db.models.fields.CharField')(max_length=256)), )) db.send_create_signal('oozie', ['Pig']) # Adding model 'Start' db.create_table('oozie_start', ( ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True)), )) db.send_create_signal('oozie', ['Start']) # Adding model 'End' db.create_table('oozie_end', ( ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), )) db.send_create_signal('oozie', ['End']) # Adding model 'Kill' db.create_table('oozie_kill', ( ('message', self.gf('django.db.models.fields.CharField')(default='Action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]', max_length=256)), ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), )) db.send_create_signal('oozie', ['Kill']) # Adding model 'Fork' db.create_table('oozie_fork', ( ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), )) db.send_create_signal('oozie', ['Fork']) # Adding model 'Join' db.create_table('oozie_join', ( ('node_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Node'], unique=True, primary_key=True)), )) db.send_create_signal('oozie', ['Join']) # Adding model 'Coordinator' db.create_table('oozie_coordinator', ( ('end', self.gf('django.db.models.fields.DateTimeField')(default=datetime.datetime(2012, 9, 7, 15, 12, 23, 992784))), ('concurrency', self.gf('django.db.models.fields.PositiveSmallIntegerField')(null=True, blank=True)), ('frequency_number', self.gf('django.db.models.fields.SmallIntegerField')(default=1)), ('workflow', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Workflow'], null=True)), ('job_ptr', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Job'], unique=True, primary_key=True)), ('frequency_unit', self.gf('django.db.models.fields.CharField')(default='days', max_length=20)), ('start', self.gf('django.db.models.fields.DateTimeField')(default=datetime.datetime(2012, 9, 4, 15, 12, 23, 992735))), ('timeout', self.gf('django.db.models.fields.SmallIntegerField')(null=True, blank=True)), ('timezone', self.gf('django.db.models.fields.CharField')(default='America/Los_Angeles', max_length=24)), ('throttle', self.gf('django.db.models.fields.PositiveSmallIntegerField')(null=True, blank=True)), ('execution', self.gf('django.db.models.fields.CharField')(max_length=10, null=True, blank=True)), )) db.send_create_signal('oozie', ['Coordinator']) # Adding model 'Dataset' db.create_table('oozie_dataset', ( ('description', self.gf('django.db.models.fields.CharField')(default='', max_length=1024, blank=True)), ('frequency_number', self.gf('django.db.models.fields.SmallIntegerField')(default=1)), ('coordinator', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Coordinator'])), ('frequency_unit', self.gf('django.db.models.fields.CharField')(default='days', max_length=20)), ('uri', self.gf('django.db.models.fields.CharField')(default='/data/${YEAR}${MONTH}${DAY}', max_length=1024)), ('start', self.gf('django.db.models.fields.DateTimeField')(default=datetime.datetime(2012, 9, 4, 15, 12, 23, 993608))), ('timezone', self.gf('django.db.models.fields.CharField')(default='America/Los_Angeles', max_length=24)), ('done_flag', self.gf('django.db.models.fields.CharField')(default='', max_length=64, blank=True)), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), )) db.send_create_signal('oozie', ['Dataset']) # Adding model 'DataInput' db.create_table('oozie_datainput', ( ('coordinator', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Coordinator'])), ('dataset', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Dataset'], unique=True)), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), )) db.send_create_signal('oozie', ['DataInput']) # Adding model 'DataOutput' db.create_table('oozie_dataoutput', ( ('coordinator', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Coordinator'])), ('dataset', self.gf('django.db.models.fields.related.OneToOneField')(to=orm['oozie.Dataset'], unique=True)), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('name', self.gf('django.db.models.fields.CharField')(max_length=40)), )) db.send_create_signal('oozie', ['DataOutput']) # Adding model 'History' db.create_table('oozie_history', ( ('submission_date', self.gf('django.db.models.fields.DateTimeField')(auto_now=True, db_index=True, blank=True)), ('job', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['oozie.Job'])), ('properties', self.gf('django.db.models.fields.TextField')()), ('oozie_job_id', self.gf('django.db.models.fields.CharField')(max_length=128)), ('submitter', self.gf('django.db.models.fields.related.ForeignKey')(to=orm['auth.User'])), ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), )) db.send_create_signal('oozie', ['History']) def backwards(self, orm): # Deleting model 'Job' db.delete_table('oozie_job') # Deleting model 'Workflow' db.delete_table('oozie_workflow') # Deleting model 'Link' db.delete_table('oozie_link') # Deleting model 'Node' db.delete_table('oozie_node') # Deleting model 'Mapreduce' db.delete_table('oozie_mapreduce') # Deleting model 'Streaming' db.delete_table('oozie_streaming') # Deleting model 'Java' db.delete_table('oozie_java') # Deleting model 'Pig' db.delete_table('oozie_pig') # Deleting model 'Start' db.delete_table('oozie_start') # Deleting model 'End' db.delete_table('oozie_end') # Deleting model 'Kill' db.delete_table('oozie_kill') # Deleting model 'Fork' db.delete_table('oozie_fork') # Deleting model 'Join' db.delete_table('oozie_join') # Deleting model 'Coordinator' db.delete_table('oozie_coordinator') # Deleting model 'Dataset' db.delete_table('oozie_dataset') # Deleting model 'DataInput' db.delete_table('oozie_datainput') # Deleting model 'DataOutput' db.delete_table('oozie_dataoutput') # Deleting model 'History' db.delete_table('oozie_history') models = { 'auth.group': { 'Meta': {'object_name': 'Group'}, 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '80'}), 'permissions': ('django.db.models.fields.related.ManyToManyField', [], {'to': ""orm['auth.Permission']"", 'symmetrical': 'False', 'blank': 'True'}) }, 'auth.permission': { 'Meta': {'unique_together': ""(('content_type', 'codename'),)"", 'object_name': 'Permission'}, 'codename': ('django.db.models.fields.CharField', [], {'max_length': '100'}), 'content_type': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['contenttypes.ContentType']""}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '50'}) }, 'auth.user': { 'Meta': {'object_name': 'User'}, 'date_joined': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime.now'}), 'email': ('django.db.models.fields.EmailField', [], {'max_length': '75', 'blank': 'True'}), 'first_name': ('django.db.models.fields.CharField', [], {'max_length': '30', 'blank': 'True'}), 'groups': ('django.db.models.fields.related.ManyToManyField', [], {'to': ""orm['auth.Group']"", 'symmetrical': 'False', 'blank': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'is_active': ('django.db.models.fields.BooleanField', [], {'default': 'True', 'blank': 'True'}), 'is_staff': ('django.db.models.fields.BooleanField', [], {'default': 'False', 'blank': 'True'}), 'is_superuser': ('django.db.models.fields.BooleanField', [], {'default': 'False', 'blank': 'True'}), 'last_login': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime.now'}), 'last_name': ('django.db.models.fields.CharField', [], {'max_length': '30', 'blank': 'True'}), 'password': ('django.db.models.fields.CharField', [], {'max_length': '128'}), 'user_permissions': ('django.db.models.fields.related.ManyToManyField', [], {'to': ""orm['auth.Permission']"", 'symmetrical': 'False', 'blank': 'True'}), 'username': ('django.db.models.fields.CharField', [], {'unique': 'True', 'max_length': '30'}) }, 'contenttypes.contenttype': { 'Meta': {'unique_together': ""(('app_label', 'model'),)"", 'object_name': 'ContentType', 'db_table': ""'django_content_type'""}, 'app_label': ('django.db.models.fields.CharField', [], {'max_length': '100'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'model': ('django.db.models.fields.CharField', [], {'max_length': '100'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '100'}) }, 'oozie.coordinator': { 'Meta': {'object_name': 'Coordinator', '_ormbases': ['oozie.Job']}, 'concurrency': ('django.db.models.fields.PositiveSmallIntegerField', [], {'null': 'True', 'blank': 'True'}), 'end': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime(2012, 9, 7, 15, 12, 23, 992784)'}), 'execution': ('django.db.models.fields.CharField', [], {'max_length': '10', 'null': 'True', 'blank': 'True'}), 'frequency_number': ('django.db.models.fields.SmallIntegerField', [], {'default': '1'}), 'frequency_unit': ('django.db.models.fields.CharField', [], {'default': ""'days'"", 'max_length': '20'}), 'job_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Job']"", 'unique': 'True', 'primary_key': 'True'}), 'start': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime(2012, 9, 4, 15, 12, 23, 992735)'}), 'throttle': ('django.db.models.fields.PositiveSmallIntegerField', [], {'null': 'True', 'blank': 'True'}), 'timeout': ('django.db.models.fields.SmallIntegerField', [], {'null': 'True', 'blank': 'True'}), 'timezone': ('django.db.models.fields.CharField', [], {'default': ""'America/Los_Angeles'"", 'max_length': '24'}), 'workflow': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Workflow']"", 'null': 'True'}) }, 'oozie.datainput': { 'Meta': {'object_name': 'DataInput'}, 'coordinator': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Coordinator']""}), 'dataset': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Dataset']"", 'unique': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}) }, 'oozie.dataoutput': { 'Meta': {'object_name': 'DataOutput'}, 'coordinator': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Coordinator']""}), 'dataset': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Dataset']"", 'unique': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}) }, 'oozie.dataset': { 'Meta': {'object_name': 'Dataset'}, 'coordinator': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Coordinator']""}), 'description': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '1024', 'blank': 'True'}), 'done_flag': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '64', 'blank': 'True'}), 'frequency_number': ('django.db.models.fields.SmallIntegerField', [], {'default': '1'}), 'frequency_unit': ('django.db.models.fields.CharField', [], {'default': ""'days'"", 'max_length': '20'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}), 'start': ('django.db.models.fields.DateTimeField', [], {'default': 'datetime.datetime(2012, 9, 4, 15, 12, 23, 993608)'}), 'timezone': ('django.db.models.fields.CharField', [], {'default': ""'America/Los_Angeles'"", 'max_length': '24'}), 'uri': ('django.db.models.fields.CharField', [], {'default': ""'/data/${YEAR}${MONTH}${DAY}'"", 'max_length': '1024'}) }, 'oozie.end': { 'Meta': {'object_name': 'End'}, 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}) }, 'oozie.fork': { 'Meta': {'object_name': 'Fork'}, 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}) }, 'oozie.history': { 'Meta': {'object_name': 'History'}, 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'job': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Job']""}), 'oozie_job_id': ('django.db.models.fields.CharField', [], {'max_length': '128'}), 'properties': ('django.db.models.fields.TextField', [], {}), 'submission_date': ('django.db.models.fields.DateTimeField', [], {'auto_now': 'True', 'db_index': 'True', 'blank': 'True'}), 'submitter': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['auth.User']""}) }, 'oozie.java': { 'Meta': {'object_name': 'Java'}, 'archives': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'args': ('django.db.models.fields.CharField', [], {'max_length': '4096', 'blank': 'True'}), 'files': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'jar_path': ('django.db.models.fields.CharField', [], {'max_length': '512'}), 'java_opts': ('django.db.models.fields.CharField', [], {'max_length': '256', 'blank': 'True'}), 'job_properties': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'job_xml': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '512', 'blank': 'True'}), 'main_class': ('django.db.models.fields.CharField', [], {'max_length': '256'}), 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}), 'prepares': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}) }, 'oozie.job': { 'Meta': {'object_name': 'Job'}, 'deployment_dir': ('django.db.models.fields.CharField', [], {'max_length': '1024', 'blank': 'True'}), 'description': ('django.db.models.fields.CharField', [], {'max_length': '1024', 'blank': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'is_shared': ('django.db.models.fields.BooleanField', [], {'default': 'False', 'db_index': 'True', 'blank': 'True'}), 'last_modified': ('django.db.models.fields.DateTimeField', [], {'auto_now': 'True', 'db_index': 'True', 'blank': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}), 'owner': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['auth.User']""}), 'parameters': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'schema_version': ('django.db.models.fields.CharField', [], {'max_length': '128'}) }, 'oozie.join': { 'Meta': {'object_name': 'Join'}, 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}) }, 'oozie.kill': { 'Meta': {'object_name': 'Kill'}, 'message': ('django.db.models.fields.CharField', [], {'default': ""'Action failed, error message[${wf:errorMessage(wf:lastErrorNode())}]'"", 'max_length': '256'}), 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}) }, 'oozie.link': { 'Meta': {'object_name': 'Link'}, 'child': ('django.db.models.fields.related.ForeignKey', [], {'related_name': ""'parent_node'"", 'to': ""orm['oozie.Node']""}), 'comment': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '1024', 'blank': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}), 'parent': ('django.db.models.fields.related.ForeignKey', [], {'related_name': ""'child_node'"", 'to': ""orm['oozie.Node']""}) }, 'oozie.mapreduce': { 'Meta': {'object_name': 'Mapreduce'}, 'archives': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'files': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'jar_path': ('django.db.models.fields.CharField', [], {'max_length': '512'}), 'job_properties': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'job_xml': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '512', 'blank': 'True'}), 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True'}), 'prepares': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}) }, 'oozie.node': { 'Meta': {'object_name': 'Node'}, 'children': ('django.db.models.fields.related.ManyToManyField', [], {'related_name': ""'parents'"", 'symmetrical': 'False', 'through': ""orm['oozie.Link']"", 'to': ""orm['oozie.Node']""}), 'description': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '1024', 'blank': 'True'}), 'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}), 'name': ('django.db.models.fields.CharField', [], {'max_length': '40'}), 'node_type': ('django.db.models.fields.CharField', [], {'max_length': '64'}), 'workflow': ('django.db.models.fields.related.ForeignKey', [], {'to': ""orm['oozie.Workflow']""}) }, 'oozie.pig': { 'Meta': {'object_name': 'Pig'}, 'archives': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'files': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'job_properties': ('django.db.models.fields.TextField', [], {'default': '\'[{""name"":""oozie.use.system.libpath"",""value"":""true""}]\''}), 'job_xml': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '512', 'blank': 'True'}), 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}), 'params': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'prepares': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'script_path': ('django.db.models.fields.CharField', [], {'max_length': '256'}) }, 'oozie.start': { 'Meta': {'object_name': 'Start'}, 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True'}) }, 'oozie.streaming': { 'Meta': {'object_name': 'Streaming'}, 'archives': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'files': ('django.db.models.fields.CharField', [], {'default': ""'[]'"", 'max_length': '512'}), 'job_properties': ('django.db.models.fields.TextField', [], {'default': '\'[{""name"":""oozie.use.system.libpath"",""value"":""true""}]\''}), 'mapper': ('django.db.models.fields.CharField', [], {'max_length': '512'}), 'node_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Node']"", 'unique': 'True', 'primary_key': 'True'}), 'reducer': ('django.db.models.fields.CharField', [], {'max_length': '512'}) }, 'oozie.workflow': { 'Meta': {'object_name': 'Workflow', '_ormbases': ['oozie.Job']}, 'end': ('django.db.models.fields.related.ForeignKey', [], {'blank': 'True', 'related_name': ""'end_workflow'"", 'null': 'True', 'to': ""orm['oozie.End']""}), 'is_single': ('django.db.models.fields.BooleanField', [], {'default': 'False', 'blank': 'True'}), 'job_properties': ('django.db.models.fields.TextField', [], {'default': ""'[]'""}), 'job_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': ""orm['oozie.Job']"", 'unique': 'True', 'primary_key': 'True'}), 'job_xml': ('django.db.models.fields.CharField', [], {'default': ""''"", 'max_length': '512', 'blank': 'True'}), 'start': ('django.db.models.fields.related.ForeignKey', [], {'blank': 'True', 'related_name': ""'start_workflow'"", 'null': 'True', 'to': ""orm['oozie.Start']""}) } } complete_apps = ['oozie'] }}}",abe@… Active Tickets,1195,Alter column not given 'default' argument for field in forwards/backwards,migrations,0.7.6,1.0,defect,andrew,new,2012-12-11T18:03:57Z,2012-12-12T14:58:23Z,"When altering a column, the default is not included in the arguments for `self.gf(...)(...)`, which causes it to be permanently dropped from the database schema, even after running the migration backwards. For example, take a look at the attached `foobar` app. When the migration status of the app is on 0002, running `migrate foobar 0003` followed by `migrate foobar 0002` will result in a different database schema than before (the effective difference is that the default is dropped on `foo_field`). Besides the fact that the default is dropped, this also seems wrong because it violates the expectation that, at the level of the database schema (that is, excluding data), a forward/backward migration pair should be inverses of each other. Interestingly enough, the default is always present in `Migration.models`. Also, the default is included in the `self.gf(...)(...)` args when a field is added.",valtron2000@… Active Tickets,1198,More sensible sort order for migrations?,commands,unknown,1.0,defect,andrew,new,2012-12-24T09:45:52Z,2012-12-24T11:21:03Z,"First, I'd be glad to implement this enhancement if it's wanted. The proposal: Sort migrations by parsing actual integers out of the file names with a regex like /^[^0-9]+(\d+)[^0-9]+\.py$/ or even /^([0-9]+)_[^0-9]+\.py$/, then cast them to int and sort by that. Presto, readable migration names! Currently, according to the docs, migrations are sorted in ASCII order, with the consequence that users need to prefix their migration version numbers with one, two, or three zeros to align them so they sort. This places a built-in limitation of 10k migrations--generous, to be sure!--but seems error-prone, especially against the use case where the user hand-creates or hand-renames a migration.",mknorman@… Active Tickets,1206,upload_to field of File/ImageField ignored,migrations,0.7.5,1.0,defect,andrew,new,2013-01-25T23:07:26Z,2013-01-29T11:19:54Z,"South completely ignores the upload_to attribute of !File/ImageField, while this doesn't cause problems in migrations that create/delete/update fields of this type, it causes problems for data migrations with these fields. The migration that gave my trouble was something like this: {{{ def forwards(self, orm): for photo in orm.Photo.objects.all(): response = urllib2.urlopen(photo.url).read() photo.image.save(photo.url[photo.url.rfind('/')+1:], ContentFile(response)) }}} The problem is that because it ignores the upload_to field, the files are created in the wrong place. I worked around it by accessing the model directly instead of through orm. I know the docs state I shouldn't do this, but I didn't see another solution.",jgastal@… Active Tickets,1214,create_index doesn't create varchar_pattern_ops index,migrations,0.7.6,1.0,defect,andrew,new,2013-02-07T16:01:20Z,2013-02-07T16:08:05Z,"With this existing code (South migration up to date): {{{ number = models.CharField(max_length=16) }}} If I change code to: {{{ number = models.CharField(max_length=16, db_index=True) number2 = models.CharField(max_length=16, db_index=True, default='foo') }}} South will create these migrations rules: {{{ db.add_column('damages_damage', 'number2', self.gf('django.db.models.fields.CharField')(default='foo', max_length=16, db_index=True), keep_default=False) db.create_index('damages_damage', ['number']) }}} and PostgreSQL log is: {{{ ALTER TABLE ""damages_damage"" ADD COLUMN ""number2"" varchar(16) NOT NULL DEFAULT 'foo'; ALTER TABLE ""damages_damage"" ALTER COLUMN ""number2"" TYPE varchar(16), ALTER COLUMN ""number2"" SET NOT NULL, ALTER COLUMN ""number2"" DROP DEFAULT; CREATE INDEX ""damages_damage_number"" ON ""damages_damage"" (""number""); CREATE INDEX ""damages_damage_number2"" ON ""damages_damage"" (""number2""); CREATE INDEX ""damages_damage_number2_like"" ON ""damages_damage"" (""number2"" varchar_pattern_ops); }}} so one index varchar_pattern_ops is missing for existing `number`. Tested with South==0.7.6, Django 1.4.3 and PostgreSQL 9.1. ",stephane.raimbault@… Active Tickets,270,startmigration --fixture option,commands,0.6.1,1.0,enhancement,andrew,assigned,2009-10-22T14:04:25+01:00,2010-05-21T21:16:52+01:00,It would be nice to have a templateable way to create a migration which loads a fixture.,andrew Active Tickets,446,introspection rules could accept callable for more flexibility,databaseapi,0.7,1.0,enhancement,carl@…,assigned,2010-04-28T21:51:53+01:00,2010-12-01T20:43:00Z,"Where the introspection rules currently require a Field attribute name (with magically-handled dots), a callable could be accepted that takes the Field instance as its only argument and returns the parameter value to use. This would allow for much more flexible handling, without a profusion of special-case options in the options dict; including simple things that are impossible now, like correct handling of a boolean Field attribute that is stored as the inverse of the parameter passed in to the Field's __init__ method. This wouldn't need to affect backwards-compatibility, as the first tuple element can be asked if it is callable(); if not, it will be treated as it is currently. I will provide a patch with tests, if the idea is accepted in principle. (In the long run, IMO it'd be more Pythonic if all introspection rules were done this way; you could get rid of the ""is_value"" special-case option in favor of a simple ""lambda f: 'the_value'""; normal attribute access could just be ""lambda f: f.attr""; etc.)",carl@… Active Tickets,449,Baselining migrations,migrations,0.7,1.0,enhancement,andrew,assigned,2010-04-29T15:11:10+01:00,2010-04-29T15:53:33+01:00,"At some stage one accumulates quite a number of migrations, especially in the team. In that case there's also migrations with same numbers, which have to be merged. Sometimes it leeads to weird errors during rollback/forward migrations. It's be nice to have an ability to 'baseline' current state of the migrations/DB to just one file (ie 0001_initial) and wipe out the remaining ones.",artem.skvira@… Active Tickets,458,Allow custom fields to define dependencies for model freezer,migrations,0.7,1.0,enhancement,andrew,assigned,2010-05-11T11:02:13+01:00,2011-06-03T13:03:49+01:00,"The field_dependencies method in the freezer (creator/freezer.py) hardcodes the determination of related models for FK, M2M etc fields. If you have a custom field that needs a dependency, but is not a subclass of one of the django classes, the freezer misses that dependency and does not add the related model definition. It is obviously not difficult to add the related model definition manually into the migration, but it would be nice if a custom field could define a callback to return the dependent models.",koen.biermans@… Active Tickets,517,Add db.delete_columns() method to API,databaseapi,unknown,1.0,enhancement,andrew,assigned,2010-07-28T04:05:42+01:00,2010-07-28T09:51:02+01:00,"Add this functionality: db.delete_columns('table_name',['col1','col2']) This would allow for much more efficient column deletion on large tables where multiple columns are being dropped.",adam@… Active Tickets,678,"If a field's default is set to an Enum, the resulting migration has a syntax error",migrations,unknown,1.0,enhancement,andrew,assigned,2010-11-24T19:58:28Z,2010-12-01T20:36:24Z,"I had code like this: ENUM1 = Enum(...) field1 = models.CharField(max_length=100, default=ENUM1.SOME_VALUE) The resulting migration had a typo, since it put the repr() of the value into the migration file: default=EnumValue(, 0, 'SOME_VALUE') It's probably a bad idea to add an object as the default - this should probably have a str(ENUM1.SOME_VALUE) instead. But the point of this ticket is better error reporting. It'd be nice if south would show an error when *creating* a migration. Right now it only shows a syntax error when running the migration.",virtue@… Active Tickets,685,add a flag to run only schema migrations,commands,0.7.2,1.0,enhancement,andrew,infoneeded,2010-12-03T23:57:29Z,2010-12-07T12:45:49Z,"The use case would be apparent if you are writing code in both production and development environments. In the dev environment, you would only want to run schema migrations, whereas in production you would want to run both schema and data migrations.",jd Active Tickets,689,Improve documentation how to create permissions,documentation,unknown,1.0,enhancement,andrew,assigned,2010-12-15T14:23:53Z,2010-12-29T12:00:45Z,"I (and other) think the documentation on how to create permissions should be improved. see http://groups.google.com/group/south-users/browse_thread/thread/39611ce39625a20f Don't get me wrong: I can live with manual creating permissions (Ticket #211), I just want better documentation.",hv@… Active Tickets,758,Improve interative console prompts readability,commands,unknown,1.0,enhancement,andrew,assigned,2011-04-18T07:17:04+01:00,2011-04-21T11:31:49+01:00,"Hi, It would really improve readability that when south asks you for what default value do you want in cases in which you don't have a default value and the field is not null the name of the field was clearly visible. In example, instead of (sample text, right now I don't have any migrations to run. $ The field 'table.field_name' has no default value... Do something like: $ ==> table.field_name $ This field has no default value... In this quick example I added '==>' to help point the column name and I also set the column name to appear alone in one line. This gives you instant recognition of the context against of having to search in the text. This ticket comes motivated from the fact that in migrations I use to spend more time looking for the field name than writing its default value.",francescortiz@… Active Tickets,941,add_column does unnecessary (and db-blocking) work,commands,0.7.3,The Future,defect,andrew,reopened,2011-10-28T09:46:55+01:00,2011-10-28T14:22:04+01:00,"when south adds a field, it does 2 alter-table commands, the second one is often unnecessary and very slow. in more detail: when doing this: {{{ db.add_column('p_thing', 'content', self.gf('django.db.models.fields.CharField')(max_length=30, null=True), keep_default=False) }}} on postgresql, the following 2 commands are executed: {{{ ALTER TABLE ""p_thing"" ADD COLUMN ""content"" varchar(30) NULL; ALTER TABLE ""p_thing"" ALTER COLUMN ""content"" TYPE varchar(30), ALTER COLUMN ""content"" DROP NOT NULL, ALTER COLUMN ""content"" DROP DEFAULT; }}} the second command is totally unnecessary: the type is already correct, it is not ""NOT NULL"", and it does not have a DEFAULT. the bigger problem is that when doing this on a db in production, the first commands finishes very fast, but the second one takes a very long time (i guess it does something to every row). so the migration will block the site's normal traffic for a very long time.",Gábor Farkas Active Tickets,979,Changing from ManyToMany to a CharField seeks to drop non existant tablename,migrations,0.7.3,The Future,defect,andrew,new,2011-12-29T19:18:18Z,2011-12-29T19:22:41Z,"South 0.7.3 Django 1.3.1 I had a model with a ManyToMany field that pointed at cms.Placholder. Then I decided to change it to a CharField that is based on a generator class providing options built from a qury of cms.Placeholder.objects.all().values('slot').distinct(). So I commented out the ManyToMany field, inserted the new CharField with its choices generator, and generated a migration. No errors so far. However when I attempt to perform the migration, it complains about a non existant tablename : {{{ django.db.utils.DatabaseError: no such table: cmsplugin_embedpagesplugin_placeholders }}} Looking at the migration I can see that it has mis-calculated the table name to drop. Notice that in migration 2, I simply had to either, manually change the table name or ignore the exception. I've attached the models.py, and both the migrations.",Zenobius Jiricek Active Tickets,1109,m2m tables greted twice,commands,0.7.5,The Future,defect,andrew,accepted,2012-06-06T15:38:00+01:00,2012-06-06T19:49:55+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) }}} ",anonymous Active Tickets,1193,Correct show of manage command in print statements.,commands,unknown,The Future,defect,andrew,new,2012-12-07T14:58:57Z,2012-12-07T15:05:04Z,"South prints '(use ./manage.py migrate to migrate these) after a syncdb and at a couple of other places. We use buildout [1] and our manage.py is named ./bin/django. Proposed fix: ""(use ./%s migrate to migrate these)"" % sys.argv[0] [1]http://jacobian.org/writing/django-apps-with-buildout/",roland@… Active Tickets,480,--show-sql option for migrate,commands,0.7.1,The Future,enhancement,andrew,assigned,2010-06-17T05:14:23+01:00,2013-04-30T12:43:23+01:00,"Somewhat similar to --db-dry-run, but outputs sql. Preferably, outputs orm queries too. Anything besides sql can be output as sql comments. Useful for debugging and sometimes replication. For example, for Slony-I one can use: {{{ ./manage.py migrate --show-sql > /tmp/ddl.sql slonik_execute_script [options] set# /tmp/ddl.sql }}} For now I use {{{ ./manage.py migrate --db-dry-run --verbosity=2 | perl -ne 'print if s/^\s*=\s(.*)\[\]$/$1/' }}} which is far from perfect. ",suor.web@… Active Tickets,509,Add commented out dependencies automatically,commands,unknown,The Future,enhancement,andrew,assigned,2010-07-07T18:08:37+01:00,2013-03-14T09:13:39Z,"Many data and schema migrations have dependencies on other models - due to foreign keys, for example. A reasonable default dependency set would be on the latest migration for all foreign keys referenced by the models in the app that is being migrated. This might be overly aggressive, however. As a compromise between the current situation of _no_ information about possible dependencies and the overly aggressive set of automatic dependencies suggested above, I propose that south add the above set of dependencies commented out, one per line, so that one could go through the list and uncomment or delete them as necessary.",david.christian@… Active Tickets,752,Make it possible to do cross-database constraint creation,databaseapi,mercurial,The Future,enhancement,andrew,assigned,2011-04-01T05:45:20+01:00,2011-04-07T18:54:50+01:00,"With Django 1.3 and the on_delete parameter to ForeignKey model fields, this could be very useful. Right now there is only delete_foreign_key(). Ironically enough, setting this to models.DO_NOTHING is when it would be most useful for South to allow changing the way constraints are created. http://docs.djangoproject.com/en/dev/ref/models/fields/#arguments It looks like foreign_key_sql() handles this under the covers. One should be able to create ""ON DELETE "", ""ON UPDATE "", ""DEFERRABLE""/""NOT DEFERRABLE"", and ""INITIALLY IMMEDIATE""/""INITIALLY DEFERRED"" or their equivalent in all the supported database engines. * PostgreSQL: http://www.postgresql.org/docs/9.0/static/sql-createtable.html, search for REFERENCES * MySQL: http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html * http://www.sqlite.org/foreignkeys.html * SQL Server: http://msdn.microsoft.com/en-us/library/ms175464.aspx * Oracle: http://www.orafaq.com/wiki/Foreign_key",dpmcgee@… Active Tickets,825,--edit flag to schemamigration/datamigration,commands,0.7.3,The Future,enhancement,andrew,new,2011-08-08T02:09:30+01:00,2011-08-09T17:09:52+01:00,"I find that lots of the time I need to edit a migration file after it has been created. I propose a patch to these two commands that allows for an '--edit' option, that will open the created file in '$EDITOR' after creating it. I have a preliminary patch for schemamigration attached.",matt@… Active Tickets,932,Support for insert+select,databaseapi,0.7.3,The Future,enhancement,andrew,accepted,2011-10-14T20:18:18+01:00,2011-10-14T21:29:46+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.",zygmunt.krynicki@… Active Tickets,965,"support ""after col_name"" in add_column",commands,unknown,The Future,enhancement,andrew,assigned,2011-11-30T18:03:51Z,2013-01-29T20:06:00Z,"After applying an add_column migration, I noticed the new columns were appended to the end of the table columns. This surprised me, because I had modified my models.py by adding fields in specific positions, and I assumed South would use that ordering. Now my table and my Model class are out of synch (with respect to field order). Could a flag be added to support this correspondence?",anonymous Active Tickets,1210,Python 3 Support,commands,mercurial,The Future,enhancement,andrew,new,2013-02-04T17:48:39Z,2013-02-04T17:52:55Z,"When trying to install South in Python 3.3, I get the following output: {{{ Running setup.py install for south File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/db/oracle.py"", line 130 print ' - no dry run output for alter_column() due to dynamic DDL, sorry' ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/db/postgresql_psycopg2.py"", line 55 print "" ~ No such sequence (ignoring error)"" ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/db/firebird.py"", line 291 except DatabaseError, e: ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/db/generic.py"", line 265 print "" = %s"" % sql, params ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/migrationcheck.py"", line 47 except Exception, e: ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/syncdb.py"", line 52 except ImportError, exc: ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/schemamigration.py"", line 185 print file_contents ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/datamigration.py"", line 71 print file_contents ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/migrate.py"", line 64 except ImportError, exc: ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/graphmigrations.py"", line 28 print ""digraph G {"" ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/convert_to_south.py"", line 41 print ""Please specify an app to convert."" ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/management/commands/startmigration.py"", line 31 print ""The 'startmigration' command is now deprecated; please use the new 'schemamigration' and 'datamigration' commands."" ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/migration/migrators.py"", line 30 print self.title(target) ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/migration/__init__.py"", line 162 print ""? You have no migrations for the '%s' app. You might want some."" % app_label ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/migration/base.py"", line 97 print ""Creating migrations directory at '%s'..."" % migrations_dir ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/creator/actions.py"", line 150 print "" ? The field '%s.%s' does not have a default specified, yet is NOT NULL."" % ( ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/creator/freezer.py"", line 45 print "" ! Cannot freeze field '%s.%s'"" % (key, field_name) ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/creator/changes.py"", line 424 print ""%r is not a valid field description."" % field_desc ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/logger.py"", line 21 raise IOError, ""SOUTH_LOGGING_ON is True. You also need a SOUTH_LOGGING_FILE setting."" ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/exceptions.py"", line 103 print ""Migration '%(migration)s' depends on unknown migration '%(depends_on)s'."" % self.__dict__ ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/modelsinspector.py"", line 404 print "" ( Nativing field: %s"" % field.name ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/tests/__init__.py"", line 30 print ""Skipping"", testfunc.__name__,""--"", message ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/tests/logic.py"", line 574 except exceptions.InconsistentMigrationHistory, e: ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/tests/db.py"", line 550 self.assertEqual(value, after, ""Change from text to char altered value [ %s != %s ]"" % (`value`,`after`)) ^ SyntaxError: invalid syntax File ""/home/lslf/python3-environments/cmip/local/lib/python3.3/dist-packages/south/orm.py"", line 230 print ""WARNING: Cannot import '%s'"" % value ^ SyntaxError: invalid syntax }}}",anonymous Active Tickets,1224,"Running ""migrate"" using PostgreSQL cause the PostgreSQL to log an error",commands,0.7.6,,defect,andrew,new,2013-03-05T13:49:00Z,2013-03-07T00:47:14Z,"Whenever I do a ""python manage.py migrate "" my PostgreSQL 9.2 server logs the following error: ""LOG: unexpected EOF on client connection with an open transaction"" This seems to cause no issues, but is just an eysore.",kimvais@… Active Tickets,439,Command responses should examine management command name,commands,0.7,1.0,defect,andrew,assigned,2010-04-24T10:12:49+01:00,2011-07-19T03:48:02+01:00,"I use virtualenv, and don't have a ./manage.py file: this makes it easy to run commands from anywhere (and DJANGO_SETTINGS_MODULE is always set in my virtualenv shell). However, the south admin commands still tell me to use ./manage.py migrate. It would be great if they would know how the management command that is currently running was called, and suggest the call of the next command the same way.",anonymous Active Tickets,703,"South does not seem to pick up ""spatial_index"" and ""db_index"" params for GeoDjango's geometry fields",migrations,0.7.3,1.0,defect,andrew,assigned,2011-01-10T22:23:22Z,2011-01-11T19:56:29Z,"South does not seem to add db_index and spatial_index parameters for GeometryField descendants. I'm creating my tables using MySQL InnoDB, which does not support spatial indexing. However, the default option for GeometryField-s is to create one - spatial_index=True. Example: {{{ class Model1(models.Model): location = models.PointField(blank=True, null=True, db_index=False, spatial_index=False }}} {{{ $ ./manage.py schemamigration myapp --initial }}} migration created : {{{ db.create_table('myapp_model1', ( ('id', self.gf('django.db.models.fields.AutoField')(primary_key=True)), ('location', self.gf('django.contrib.gis.db.models.fields.PointField')(null=True, blank=True)), }}} When I try to apply the migration, MySQL blows up with an exception that SPATIAL_INDEX is not allowed - both because I'm using InnoDB, and because my field is null=True. The workaround was to manually add the spatial_index=False option to the migration: {{{ ('location', self.gf('django.contrib.gis.db.models.fields.PointField')(null=True, blank=True, spatial_index=False)), }}} --- MacOS 10.6.6 MySQL 5.5.8 Django 1.2.4 South 0.7.3 --- Other than that - congratulations! - you guys did a great job :o) Cheers, Boris",regs@… Active Tickets,1184,python 2.4 compat fix for 0.7.6,commands,0.7.6,1.0,defect,andrew,new,2012-10-23T09:36:57+01:00,2012-10-23T10:01:54+01:00,"python 2.4 compat fix for 0.7.6 (if else, try/finally).",paulius@… Active Tickets,574,Put docstring on `migartions/__init__.py`,commands,0.7.2,1.0,enhancement,andrew,assigned,2010-09-03T12:28:29+01:00,2010-09-03T16:30:11+01:00,"Have South automatically put a docstring on `migartions/__init__.py`, saying something like '''South migrations for the `polls` app.'''",cool-rr@… Active Tickets,930,define Command.args for schemamigration,documentation,0.7.3,1.0,enhancement,andrew,accepted,2011-10-02T19:16:28+01:00,2011-10-03T13:38:34+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.) ",eric@… Active Tickets,956,Fixtures from migrations - add warning,documentation,0.7.3,1.0,enhancement,andrew,accepted,2011-11-17T03:36:51Z,2012-03-14T16:48:32Z,"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",szabtam@… Active Tickets,1140,Additional error handling for 'app' argument,commands,mercurial,The Future,enhancement,andrew,accepted,2012-07-23T17:38:10+01:00,2012-07-24T16:06:40+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.",anonymous