django-south

Django south circular dependency

久未见 提交于 2019-12-05 02:57:34
I have an app (let's call it MyApp) in a Django 1.5 project. MyApp defines a custom user model (MyUser). The project uses another app (AnotherApp) which references MyUser. MyApp references fields in AnotherApp. Everything has been working fine on my development laptop. I'm attempting to deploy my project on a server, and when I come to the migrate step, MyApp fails due to a dependency to AnotherApp, and AnotherApp fails on a dependency to MyApp (I have tried migrating the apps independently). Both are failing on their respective first migrations (0001) Running migrations for myapp: - Migrating

There is no South database module 'south.db.postgresql_psycopg2' for your database django

我怕爱的太早我们不能终老 提交于 2019-12-05 01:25:30
I have a django app with version as 1.6.5 , i am trying to upgrade it to 1.8 , but on the way i got the below error right after the django version was increased to 1.8 There is no South database module 'south.db.postgresql_psycopg2' for your database. Please either choose a supported database, check for SOUTH_DATABASE_ADAPTER[S] settings, or remove South from INSTALLED_APPS. Code INSTALLED_APPS = [ 'django_messages', 'avatar', 'tinymce', 'south', 'tracking', ...... ] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'HOST': '127.0.0.1', 'NAME': 'xxxxxx', 'USER':

How to disable south debug logging in django?

扶醉桌前 提交于 2019-12-05 00:01:59
When I run my tests in Django, after a fail I got several pages of debug output from South, like these: south: DEBUG: south execute "CREATE INDEX "sometable_4d5bad5" ON "video_playable" ("network_id");" with params "[]" south: DEBUG: south execute "CREATE INDEX "sometable_790e6d98" ON "video_playable" ("published");" with params "[]" south: DEBUG: south execute "CREATE INDEX "sometable_72312277" ON "video_playable" ("archived");" with params "[]" And with all this logging output, the relevant error messages are lost in a sea of garbage. Is there a way to disable this ouput? Put this somewhere

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

旧巷老猫 提交于 2019-12-04 22:10:07
问题 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

Using Django, South and Sqlite during development [closed]

空扰寡人 提交于 2019-12-04 17:41:34
I'm new to Python (2.7) and Django (1.5) and am working through the Django book whilst making a hobby site. I'm using Sqlite3 as dev db, but in production I intend to us MySQL. South looks like a great solution for database schema migration management, but it doesn't play well with Sqlite. I'm now tempted to install MySQL on my dev machine, but wonder if there's a way to avoid that. I'd appreciate knowing a simple, practical solution to this problem, if anyone knows of one. Edit: I meant a programmatic solution (for those that feel this is off topic). I imagined there may be a way to use

Django South migration conflict while working in a team

戏子无情 提交于 2019-12-04 17:36:17
问题 I have a short question about how to use Django-South while working in a team. What happens if two people simultaneously create migration file on changes to the same file? For example, A and B are working on same Django app. They are working in different branch and both at migration 005. Now, both A and B modifies apple/models.py and created migration file using startmigration. They are both at migration 006 but with completely different migration file 006. I guess when they merge their

Why use South during initial development?

你说的曾经没有我的故事 提交于 2019-12-04 17:06:25
问题 I'm wondering about the advantages of using (django) South during heavy initial development of a project. At the early stages of development there's normally rapid model changing, frequent branching and merging (especially if you use a development strategy like git-flow) and very little, if any, stored data. Why would you want to keep of these initial model changes? What are the advantages/disadvantages? I'm under the impression that it's easier to wait until the development settles down (and

Django south migration - Adding FULLTEXT indexes

旧巷老猫 提交于 2019-12-04 16:41:44
问题 I need to add a FULLTEXT index to one of my Django model's fields and understand that there is no built in functionality to do this and that such an index must be added manually in mysql (our back end DB). I want this index to be created in every environment. I understand model changes can be dealt with Django south migrations, but is there a way I could add such a FULLTEXT index as part of a migration? In general, if there is any custom SQL that needs to be run, how can I make it a part of a

Django - Change a ForeignKey relation to OneToOne

青春壹個敷衍的年華 提交于 2019-12-04 10:28:40
问题 I am using South with my Django app. I have two models that I am changing from having a ForeignKey relation to having a OneToOneField relation. When I ran this migration on my dev database, it ran fine. When the migrations get ran as part of creating a test database, the latest migration fails with a MySQL 1005 error: "Can't create table mydb.#sql-3249_1d (errno: 121)". Doing some Googling revealed that this is usually a problem with trying to add a constraint with the same name as an

south django migrate

北慕城南 提交于 2019-12-04 09:24:44
I just did: python manage.py schemamigration TestDBapp1 --initial python manage.py schemamigration TestDBapp1 --auto Successfully. But if I enter: python manage.py migrate TestDBapp1 I get this: sqlite3.OperationalError: table "TestDBapp1_xyz" already exists What could be the problem? I suspect that you already executed syncdb which created the tables. South tries to create them again during migrate and naturally the database complains. To avoid this you have to tell South to " fake " the initial migration. python manage.py migrate TestDBapp1 --fake As the name indicates this pretends to