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

[mahmud@…]

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

class Restaurant(models.Model):
  LIVE_STATUS = 1
    INACTIVE_STATUS = 2
    STATUS_CHOICES = (
        (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',
                      self.gf('django.db.models.fields.IntegerField')(default=2, db_index=True),
                      keep_default=False)

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
   = SET FOREIGN_KEY_CHECKS=0; []
   = SET FOREIGN_KEY_CHECKS=0; []
   = 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`); []
   = SET FOREIGN_KEY_CHECKS=0; []
   = 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`); []
   = SET FOREIGN_KEY_CHECKS=0; []
 - 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 settings.py file, I have south ignore djcelery migration tracking:

SOUTH_MIGRATION_MODULES = { "djcelery" : "ignore" }

Thank you!

[mahmud@…]

Some other things worth mentioning:

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

[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: ​http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Please mark this bug invalid.

[andrew]

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.