Привет!
Django==1.2.3+south question.

Ситуация такая: код эволюционирует, а с ним и схема БД (новые столбы, таблички, изменения, в общем ALTERы)
Вручную базу обновлять, синхронизировать модели -  в лом => Enter migrations.

Играюсь с Югом (python2.5), в смысле south.
На своем компе A инициализирую миграции приложения:

добавляю миграционные данные в p4 (i.e. version control)
обновляю код на тестовом боксе, комп B с немигрированной базой (более старой), обновляю код, запускаю:

Кричит на меня: мол не могу считать миграции нужного человечеству модуля 'django.contrib.auth'.
Круто! (оказывается на боксе A действительно в django/contrib/auth появился каталог "migrations")

Залезаю (на боксе А) в app2/migrations/__0001_initial.py оригинального (не auth) приложения, от которого зависит мое начальное app1, внутри проекта к которому принадлежат оба приложения. Там добавляю 'django.contrib.auth' перед другой зависимостью. Запускаю заново

И работает. Но: мне пришлось вмешиваться в работу этого south.
это неудобно, не масштабируемо.

Вижу так: существует граф зависимостей моделей, всяких внешних ключей.
Если следовать вышеизложенному методу, значит с каждым core модулем мне надо будет корячиться и добавлять их в ручную.
Не хорошо.

• Нет ли более умного способа ?
• Можно как-то в коде модуля указать, что миграции системного модуля реализовавшего внешний ключик - не нужны ?
• Может есть более умный струмент ?
• Или может быть более перспективно все модули впихнуть в virtualenv приложения, и поставлять приложение в каталоге со "своим" питоном и его модулями ?

побеседуем ?



Это сообщение отредактировал(а) bilbobagginz - 23.12.2010, 09:39

добавил уведомления...себе на мыло.

Ничего не понял. Что вы хотите сделать? Опишите пожалуйста по человечески и с кодом.

Editorial: зачем постить dummy пост чтобы подписаться на уведомления?

Daevaorn, извиняюсь за неясность.
по пунктам:



этот параграф описывает ситуацию и проблему:

когда 

• проект django состоит из нескольких приложений
• приложения работают друг с другом
• данные лежат во внешней (настоящей) БД (DBMS), напр. в Оракле
• код растет и развивается

создается нужда изменять схему БД.
эта нужда обостряется когда и код и бд - боевые, и бегут несколько версий кода.
т.е. нужно удобный инструмент держать код и базу данных в синхронизации, с возможностью добавок в схему, без потери данных.
с возможным рефакторингом таблиц/колонок (говоря таблицами и колонками)
этот процесс синхронизации эволюции кода с базой данных называют "миграцией" (или "мутацией", или "эволюцией схемы БД", терминология переводится с англ., может в русской терминологии это как-то иначе именуют)
Есть несколько инструментов реализации этих "миграций".
сейчас тестирую south и о нем идет речь.

ХОЧУ: иметь удобные миграции БД с версии на версию.


кода тут практически нет.
1. установка south:

2. добавка модуля последним в settings.py переменной INSTALLEDֹ_APPS:

3. работа через manage.py:

это ессно делается на разных машинах, 
чтобы изменения версии но.N на бд но.1 "мигрировали" на бд но. 2., 
чтобы можно было обновить код до версии но.N до запуска версии N с базой но. 2

ситуация проясняется ?


Это сообщение отредактировал(а) bilbobagginz - 23.12.2010, 12:03

bilbobagginz, Вы опять написали много букв ни о чем и опять без толку

Проблема у вас в чем? South хороший и проверенный инстремент. Если у вас именно с ним проблема, то с большой долей вероятности вы им просто не правильно пользуетесь.

это не вопрос из серии "помогите понять почему не компиляется код!"
я приглашаю на дискуссию

чтобы понять лучше - что я не так делаю. а может быть и не "не так".

Daevaorn, 

Раскопки дошли до корня проблем: стало понятно что south не очень хорошо протестирован с ораклом (не спрашивайте почему оракл работает у нас с джангой), результирующий SQL вылетал с ошибками :(
Чтобы починитъ генерируемый SQL извратнулись monkey-patch-ем и перегрузили метод south south.db.generic.column_sql()
который создавал при опр. условиях неперевариваемый для оракла SQL.
Кроме этого было бы удобно, если бы south мог выплевывать SQL при флажке --db-dry-run.
проблема: этот обезьян работает только из инстанциированного сервера, а хотелось бы без запуска, всухую (т.е. сейчас патч работает из нашего кода, а хотелось бы, чтобы он работал из кода south.

В общем еще немного поиграемся, и начнем подкидывать патчи в south.

всем мир.

Добавлено через 3 минуты и 54 секунды
кстати, по ходу в коде south нашего патча пока нет, а вышел уже джанго 1.2.4
И обещают скоро south внедрить в django.core.*



Это сообщение отредактировал(а) bilbobagginz - 28.12.2010, 00:27