Ticket #1162 (closed defect: invalid)

Opened 20 months ago

Last modified 20 months ago

South 0.7.5/0.7.6 appears to rename table names to lowercase when adding a simple field to an existing model

Reported by: mahmud@… Owned by: andrew
Priority: major Milestone:
Component: migrations Version: 0.7.6
Keywords: lowercase table name Cc:


I have a model which I want to add a simple integer field on:

class Restaurant(models.Model):
        (LIVE_STATUS, 'Live'),
        (INACTIVE_STATUS, 'Inactive'),
  status = models.IntegerField(choices=STATUS_CHOICES, db_index=True, default=INACTIVE_STATUS)

Before running this migration, my table's name is Restaurant_restaurant (because it's the restaurant model inside of the app "Restaurant"). When I run the following migration through south:

def forwards(self, orm):
        # Adding field 'Restaurant.status'
        db.add_column('Restaurant_restaurant', 'status',
            'django.db.models.fields.IntegerField')(default=2, db_index=True),

def backwards(self, orm):
        # Deleting field 'Restaurant.status'
        db.delete_column('Restaurant_restaurant', 'status')

Running this migration on the command line with verbosity level = 2 yields the following output:

Running migrations for Restaurant:
 - Migrating forwards to 0002_auto__add_field_restaurant_status.
 > Restaurant:0002_auto__add_field_restaurant_status
   = ALTER TABLE `Restaurant_restaurant` ADD COLUMN `status` integer NOT NULL DEFAULT 2; []
   - no dry run output for alter_column() due to dynamic DDL, sorry
   = CREATE INDEX `Restaurant_restaurant_c9ad71dd` ON `Restaurant_restaurant` (`status`); []
   = ALTER TABLE `Restaurant_restaurant` ADD COLUMN `status` integer NOT NULL DEFAULT 2; []
   = ALTER TABLE `Restaurant_restaurant` ; []
   = ALTER TABLE `Restaurant_restaurant` MODIFY `status` integer NOT NULL;; []
   = ALTER TABLE `Restaurant_restaurant` ALTER COLUMN `status` DROP DEFAULT; []
   = CREATE INDEX `Restaurant_restaurant_c9ad71dd` ON `Restaurant_restaurant` (`status`); []
 - Loading initial data for Restaurant.
::: loads some data :::
Installed 26 object(s) from 2 fixture(s)

Now with the migration run, upon inspection the table is now named "restaurant_restaurant" instead of "Restaurant_restaurant"

This issue has caused us to decide to hold out on south for now on production migrations because we're using a UNIX operating system in which our table name case sensitivity matters. Please feel free to let me know of any extra information you may need or if there's some setting that I may have enabled to cause this to happen.

The only other thing that might be of interest is that in my file, I have south ignore djcelery migration tracking:

SOUTH_MIGRATION_MODULES = { "djcelery" : "ignore" }

Thank you!


Change History

comment:1 Changed 20 months ago by mahmud@…

Some other things worth mentioning:

  • Using MySQL
  • Using South 0.7.6
  • The above was tested on Mac OSX

comment:2 Changed 20 months ago by mahmud@…

Sorry for the confusion. Turns out this isn't a south issue at all but rather the way MySQL was configured on my machine. MySQL will sometimes rename table names on specific statements:

Please mark this bug invalid.

comment:3 Changed 20 months ago by andrew

  • Status changed from new to closed
  • Resolution set to invalid

Ah, right, good to know - this is why it's generally good practice to stick with all-lowercase on most databases, the handling can sometimes be very odd.


Add a comment

Modify Ticket

as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.