Error auto creating backwards migration for custom fields

[andrew@…]

When I ran an auto migration on my schema from 0.6.2 to trunk, even though I hadn't changed anything in my models, it still said that my custom fields had changed (I'm assuming this has something to due with the new introspection stuff). It created the following methods:

    def forwards(self, orm):
        
        # Changing field 'UserProfile.cell_phone'
        db.alter_column('main_userprofile', 'cell_phone', self.gf('django.contrib.localflavor.us.models.PhoneNumberField')(max_length=20, null=True, blank=True))

        # Changing field 'Tenant.api'
        db.alter_column('main_tenant', 'api', self.gf('appfirst.main.models.RandomIntegerField')())

        # Changing field 'Dashboard.random'
        db.alter_column('main_dashboard', 'random', self.gf('appfirst.main.models.RandomIntegerField')())
    
    
    def backwards(self, orm):
        
        # Changing field 'UserProfile.cell_phone'
        db.alter_column('main_userprofile', 'cell_phone', self.gf('django.contrib.localflavor.us.models.PhoneNumberField')(null=True, blank=True))

        # Changing field 'Tenant.api'
        db.alter_column('main_tenant', 'api', self.gf('RandomIntegerField')(_('API Key')))

        # Changing field 'Dashboard.random'
        db.alter_column('main_dashboard', 'random', self.gf('RandomIntegerField')(_('Random number')))

Notice how in the forwards method it has the full path for my custom field RandomIntegerField?, but in the backward method it doesn't. Then, when I try to do a backwards migration I obviously get an error

...
  File "/Users/acarman/Development/appfirst/frontend/appfirst/main/migrations/0021_move_to_trunk.py", line 27, in backwards
    db.alter_column('main_tenant', 'api', self.gf('RandomIntegerField')(_('API Key')))
  File "/Library/Python/2.6/site-packages/South-0.7_pre-py2.6.egg/south/v2.py", line 12, in gf
    return ask_for_it_by_name(field_name)
  File "/Library/Python/2.6/site-packages/South-0.7_pre-py2.6.egg/south/utils.py", line 27, in ask_for_it_by_name
    ask_for_it_by_name.cache[name] = _ask_for_it_by_name(name) 
  File "/Library/Python/2.6/site-packages/South-0.7_pre-py2.6.egg/south/utils.py", line 16, in _ask_for_it_by_name
    module = __import__(modulename, {}, {}, bits[-1])
ImportError: No module named RandomIntegerField

If I add in the full path by hand, it works perfectly.

[anonymous]

Another problem I noticed with this. Before my schema for Tenant and Dashboard (the two tables with the RandomIntegerField?) are:

CREATE TABLE "main_dashboard" ("tenant_id" integer NOT NULL PRIMARY KEY, "random" integer NOT NULL DEFAULT 0);
CREATE TABLE "main_tenant" ("id" integer NOT NULL PRIMARY KEY, "company" varchar(32) NOT NULL, "created" datetime NOT NULL, "backend" varchar(200) NOT NULL DEFAULT 'http://backend.appfirst.com/', "api" integer NOT NULL DEFAULT 0, "plan_on" bool NOT NULL DEFAULT True, "collector_bucket" integer NOT NULL DEFAULT 0, "api_on" bool NOT NULL DEFAULT True, "insight_on" bool NOT NULL DEFAULT True, "dashboard_on" bool NOT NULL DEFAULT True, "alerting_on" bool NOT NULL DEFAULT True);

When I run above migration their schema becomes

CREATE TABLE "main_dashboard" ("tenant_id" integer, "random" "random" integer NOT NULL);
CREATE TABLE "main_tenant" ("created" datetime, "plan_on" bool, "company" varchar(32), "api_on" bool, "alerting_on" bool, "dashboard_on" bool, "api" "api" integer NOT NULL, "collector_bucket" integer, "id" integer, "insight_on" bool, "backend" varchar(200));

They've lost their primary key attributes!!

[andrew]

Firstly, the first error unfortunately _has_ to occur; there's no way of knowing the old, direct import is the same as the new long path. I'll add something in the documentation about upgrading from 0.6.2 and custom fields (it's best to manually stick the full path in all the models{} dict entries in every migration).

The second error seems to be tangentially related; what database are you using? SQLite, by chance? (I have my suspicions of what the issue is).

[anonymous]

Replying to andrew:

Firstly, the first error unfortunately _has_ to occur; there's no way of knowing the old, direct import is the same as the new long path. I'll add something in the documentation about upgrading from 0.6.2 and custom fields (it's best to manually stick the full path in all the models{} dict entries in every migration).

The second error seems to be tangentially related; what database are you using? SQLite, by chance? (I have my suspicions of what the issue is).

Yea some documentation for the first problem would be completely fine.

Yup, I'm using sqlite.

[andrew]

Alright, the new docs/release notes have a note about the field name conversion, now.

I'm fixing the primary key error.

[andrew]

Primary key error fixed in [a4e78540f46e].