django-south | 易学教程

Django-south not detecting DB changes

阅读更多关于 Django-south not detecting DB changes

问题 I have updated our project from svn and I have new migration files. When I use : ./work/manage.py schemamigration mypackage --auto I have this message: Nothing seems to have changed. But the database has changed! Why south couldn't detect any change? Thanks in advance 回答1: If you already have the migration files, there is no need to run schemamigration as that just generates the migration files. To apply the migration files to the database, run: ./work/manage.py migrate mypackage --merge The

Upgrading from Django 1.6 (with south) to 1.8 doesn't modify 'last_login' on the user table

阅读更多关于 Upgrading from Django 1.6 (with south) to 1.8 doesn't modify 'last_login' on the user table

问题 I have upgraded from Django 1.6.5 (with south migrations) to Django 1.8. I have followed the instructions here: https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south So, I remove South, delete my previous migrations and run python manage.py makemigrations which makes a new migration file. Then I run python manage.py migrate --fake-initial to fake the initial migration. Then I run python manage.py migrate . It all runs fine with no errors. I have a custom user model

Django: models aren't being recognized by syncDB or south after they have been refactored into separate files

阅读更多关于 Django: models aren't being recognized by syncDB or south after they have been refactored into separate files

I had a large models file with all the classes and stuff and it was hard to maintain all in one file. So I've refactored that into a model folder, init .py and files one per each class. then I did manage_noDebug.py schemamigration picviewer --auto manage_noDebug.py schemamigration migrate picviewer and south removed the tables from the database but hasn't added the model_* tables as I thought it would. Can I get it to pick up my model files now? manage_noDebug.py sql picviewer output from the above is empty the structure of my folders is: picviewer /models/ init .py Picture.py paperType.py ...

Django & South: Adding new field but DatabaseError occurs “table already exists”

阅读更多关于 Django & South: Adding new field but DatabaseError occurs “table already exists”

问题 In trying to add a new field to a preexisting Model/table, I get a DatabaseError with 'table already exists.' I have run migrations before this one so I am a bit puzzled why adding a new field would pop up this error. Commands executed: python manage.py schemamigration app --auto python manage.py migrate app Previous SO questions like this were answered with faking a migration. python manage.py migrate app --fake python manage.py migrate app The problem that arises from this is that the

Changing Django database backend from MySql to PostgreSQL

阅读更多关于 Changing Django database backend from MySql to PostgreSQL

问题 I use Django 1.2 and 1.3 and MySql backends. Once in while a get an error message when migrating my MySql database with South: ! 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. ... ! The South developers regret this has happened, and would ! like to gently persuade you to consider a slightly ! easier-to-deal-with DBMS I

Django South - turning a null=True field into a null=False field

阅读更多关于 Django South - turning a null=True field into a null=False field

问题 My question is, what is the best practice for turning a null=True field into a null=False field using Django South. Specifically, I'm working with a ForeignKey . 回答1: You should write first a data migration: http://south.aeracode.org/docs/tutorial/part3.html and then make the schemamigration. 回答2: If you want to turn nullable ForeignKey into non-nullable one, then it can be problematic if you have any rows with NULL for that field (column). In such case you need to either remove or fix them -

What does a South datamigration do compared to a schemamigration?

阅读更多关于 What does a South datamigration do compared to a schemamigration?

问题 I recently began digging into the South documentation and discovered that it had two distinct types of migrations: schemamigration datamigration As a result of my ignorance, I've always used schemamigrations for everything. In other words, even if I had something that was truly a "data migration", I'd simply used South's schemamigration to convert the data (with no apparent consequences). As I read the documentation, I'm not seeing a fault in this approach. Does anyone know the fundamental

Custom user models and South

阅读更多关于 Custom user models and South

I'm trying to use a custom user model in the most basic way, extending AbstractUser as described at Extending Django’s default User . But, I'm not sure how to properly make this work with South. I'm running into a problem when doing an initial schema migration with Here's what happening: I've got my extended user class, Player , in my class tournaments , which is enabled in settings.INSTALLED_APPS . To perform an initial syncdb , the tournaments app must be enabled. Otherwise I get this error: $ ./manage.py syncdb CommandError: One or more models did not validate: auth.user: Model has been

Migrate Django model to unique_together constraint

阅读更多关于 Migrate Django model to unique_together constraint

I have a model with three fields class MyModel(models.Model): a = models.ForeignKey(A) b = models.ForeignKey(B) c = models.ForeignKey(C) I want to enforce a unique constraint between these fields, and found django's unique_together , which seems to be the solution. However, I already have an existing database, and there are many duplicates. I know that since unique_together works at the database level, I need to unique-ify the rows, and then try a migration. Is there a good way to go about removing duplicates (where a duplicate has the same (A,B,C)) so that I can run migration to get the

Changing South Migration Directory

阅读更多关于 Changing South Migration Directory

How do you change the location where South looks for an app's migrations? By default, South assumes an app's migrations are in /migrations. However, I've migrated the model of a third-party package which is installed at /usr/local/lib/python-2.6/dist-packages/, so South is looking for migrations there, instead of the location of my custom codebase. In settings.py: SOUTH_MIGRATION_MODULES = { 'books': 'myproject.app_name.migrations', } 来源： https://stackoverflow.com/questions/5994420/changing-south-migration-directory