Ticket #1120 (closed defect: wontfix)

Opened 3 years ago

Last modified 2 years ago

South generates excess 'alter table ..._id_seq' statements when renaming child table (postgres)

Reported by: Mike Fogel Owned by: andrew
Priority: minor Milestone: 1.0
Component: migrations Version: 0.7.5
Keywords: Cc: mike@…


Start with a test app, models.py:

from django.db import models

class Amphibian(models.Model):
    age = models.IntegerField()
    name = models.CharField(max_length=30)

class Lizard(Amphibian):
    color = models.CharField(max_length=30)

Load that up:

(app) mfogel@cairo:~/prism/web.git (develop *$%=)
[5446]$ django-admin.py schemamigration southtest --initial
Creating migrations directory at '/Users/mfogel/prism/web.git/django-apps/southtest/migrations'...
Creating __init__.py in '/Users/mfogel/prism/web.git/django-apps/southtest/migrations'...
 + Added model southtest.Amphibian
 + Added model southtest.Lizard
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate southtest
(app) mfogel@cairo:~/prism/web.git (develop *$%=)
[5447]$ django-admin.py migrate southtest
Running migrations for southtest:
 - Migrating forwards to 0001_initial.
 > southtest:0001_initial
 - Loading initial data for southtest.
Installed 0 object(s) from 0 fixture(s)

Now in your models.py, change the name 'Lizard' to 'Crocodile'. Manually make a migration do to this table rename:

import datetime
from south.db import db
from south.v2 import SchemaMigration
from django.db import models

class Migration(SchemaMigration):

    def forwards(self, orm):
        "Rename Lizard to Crocodile"
        db.rename_table('southtest_lizard', 'southtest_crocodile')

    def backwards(self, orm):
        "Rename Crocodile to Lizard"
        db.rename_table('southtest_crocodile', 'southtest_lizard')

    models = {
        'southtest.amphibian': {
            'Meta': {'object_name': 'Amphibian'},
            'age': ('django.db.models.fields.IntegerField', [], {}),
            'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
            'name': ('django.db.models.fields.CharField', [], {'max_length': '30'})
        'southtest.crocodile': {
            'Meta': {'object_name': 'Crocodile', '_ormbases': ['southtest.Amphibian']},
            'amphibian_ptr': ('django.db.models.fields.related.OneToOneField', [], {'to': "orm['southtest.Amphibian']", 'unique': 'True', 'primary_key': 'True'}),
            'color': ('django.db.models.fields.CharField', [], {'max_length': '30'})

    complete_apps = ['southtest']

Applying that migration gives the following errors (which aren't really fatal, migration keeps going). But they look scary.

app) mfogel@cairo:~/prism/web.git/django-apps/southtest (develop *$%=)
[5462]$ django-admin.py migrate southtestRunning migrations for southtest:
 - Migrating forwards to 0002_rename_lizard_to_crocodile.
 > southtest:0002_rename_lizard_to_crocodile
ERROR:  relation "southtest_lizard_id_seq" does not exist
STATEMENT:  ALTER TABLE "southtest_lizard_id_seq" RENAME TO "southtest_crocodile_id_seq";
FATAL ERROR - The following SQL query failed: ALTER TABLE "southtest_lizard_id_seq" RENAME TO "southtest_crocodile_id_seq";
The error was: relation "southtest_lizard_id_seq" does not exist

 - Loading initial data for southtest.
Installed 0 object(s) from 0 fixture(s)

This is on postgres 9.1, using django 1.4 and south 0.7.5

Change History

comment:1 Changed 3 years ago by andrew

  • Status changed from new to closed
  • Resolution set to wontfix
  • Milestone set to 1.0

This is actually by design - the backend tries to rename any ID sequence and then if that fails just continues (South in fact has several places where it'll deliberately try operations to see if they fail). The bug here, if anything, is that South doesn't turn off database output logging while it's running migrations, but someone is looking at that already (though there's not a ticket for it yet).

comment:2 Changed 3 years ago by mrmachine

I just hit this issue on a table that uses a CharField as the primary key. It took me a while to figure out what is going on (by looking at south source) and that the error being generated is actually not "fatal".

I see that there is additional output if self.debug is non-empty that explains the problem. I'd like to see either the fatal error silenced, or the additional explanation output along-side it whenever it occurs, to save people the time in trying to figure out if their migration is working and if this is a bug in South.

Is there still no other ticket for silencing database output? If not, how about just changing the title of this one from "excess alter table statements" to "excess database errors" :)

comment:3 Changed 3 years ago by bendavis78@…

I went ahead and created a followup ticket. http://south.aeracode.org/ticket/1247

comment:4 Changed 2 years ago by sinanm89



to your settings.py will fix this error

Note: See TracTickets for help on using tickets.