South — новый клёвый syncdb

[miolini]

Как хорошо с hibernate.

[alex_blank]

мне больше нравится db4o, сразу объектная БД и с LINQ в .NET дружит (т.е. запросы к ней поддерживаются синтаксисом языка, в отличие от Hibernate)

[miolini]

Пока у вас не появится более менее сложные запросы на большие куски данных — всё будет хорошо. Это же odbms.

[romik]

Как будто Hibernate умеет обновлять схему. Те же проблемы.

[miolini]

Что значит «как будто?

[romik]

А что, умеет? hibernate.hbm2ddl.auto = update не считается, так как оно умеет только добавлять новые поля. Или уже научилось менять и удалять?

[miolini]

Почему же не считается? Он приводит схему базы к такому виду, чтобы маппинги работали. А на менять и удалять есть create-drop.

[romik]

Потому что после update получаются всякие безобразия. То not-null поле из базы не удалилось и вставка не работает, то размер поля сменился и иногда что-нибудь падает. Особенно напрягает слово иногда, так как про то, что схема могла измениться, к этому моменту уже забываешь.

В общем, update штука ошибкоопасная, хоть и полезная в процессе разработки. Для production придётся менять схему вручную или разрабатывать автомигратор a-la south.

[miolini]

Не понял — вы в продакшен хотите использовать какие-то вариации на тему обновления схемы? С ума сошли?

[romik]

А вы считаете, что в продакшн схема никогда не должна меняться?

[krig]

У Джанго, конечно, не все хорошо в плане обновления схемы, но и не так плохо, как вы описываете.
python manage.py reset [appname]
И схема будет обновлена.
Есть, правда, и огромный недостаток, который не позволяет выполнять команду на продакш сервере — вся данные из таблиц приложения очищаются.

А вобще, за инструмент огромное спасибо! Сам некоторое время столкнулся с такой проблемой — пока что делал как написано в мануале Джанго — писал руками альтеры =)

[alex_blank]

ну, так резет ведь убивает содержимое базы, а это даже при начальной разработке сильно мешает — приходится заново 'рыбу' (тестовые данные) генерить

[iwuvjhdva]

Fixtures частично спасают ситуацию.

[alex_blank]

btw, я бы побоялся использовать South «как есть» на продакшене — мало ли, какую херню он сгенерит

неплохо бы там сделать режим предпросмотра SQL statements при миграции…

[spoof]

а зачем менять бд на продакшене? :) по-идее все должно быть уже стабильно и вноситься маленькие фиксы :)

[alex_blank]

это в теории :)

[l0rda]

Я использую deseb(http://code.google.com/p/deseb/) и не имею никакого гемороя.

[l0rda]

а зачем наследоваться от User?

не имел таких проблем, на 1.0 я не тестировал, проект крутится на предыдущей версии
но в целом отличная штука, проблем не имею с ним

[voidus]

Всё пофиксили, замечательно работает.

[voidus]

В смысле, что с Django 1.0 работает… с вашей проблемой не сталкивался.

[kmike]

Выбирал из south и django-evolution.
Остановился на последнем, т.к. можно вручную миграции не описывать, ну и идеологии немножко разные у них.

[spoof]

я тоже на django-evolution остановился

[termt]

туда же django evolution

[dbf]

Так есть же deseb где не надо руками писать миграции, а он сам сравнивает модель со структурой бд.

[sgtpep]

Слишком наворочено, решение добавляет лишних уровней абстракции.
Я обхожусь скриптом, который удаляет все таблицы, запускает syncdb и загружает начальные данные (fixtures).

Пример CMD-скрипта:

echo SHOW TABLES; > dump.sql
C:\Server\usr\local\mysql5\bin\mysql_run_to_import_dumps.exe -D ИМЯ_БД < dump.sql > tables.txt
echo ; > dump.sql
REM Тут у нас обход каждой строки в списке имен таблиц
for /f "tokens=* delims=\r\n skip=1" %%t IN (tables.txt) do (
    REM Тут мы можем для отдельных таблиц добавить условия, чтобы, например, пропустить DROP
    echo DROP TABLE %%t; >> dump.sql
)
C:\Server\usr\local\mysql5\bin\mysql_run_to_import_dumps.exe -D ИМЯ_БД < dump.sql
del tables.txt
del dump.sql

manage.py syncdb --noinput
manage.py loaddata fixtures/data.json

Единственный минус — надо практически вручную вносить изменения в fixtures, но использовать fixtures — это завсегда полезная практика.

[Lolka]

Всегда пользовался django-evolution. Уже даже приспособился к некоторым его «особенностям». Было бы классно, если бы в самой джанге был полноценный мигратор, как в Ruby on Rails, к примеру.

[mykir]

Автор!!! КОНКРЕТНОЕ БОЛЬШОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБИЩЕ!!!

п.с. начинающий питоно-дажнгер прогер столкнувшийся с такойже проблемой.

[DmitryKoterov]

Вообще, странно оно как-то… Джанге уже несколько лет от роду, а встроенного мигратора (хоть какого-то, хоть ручного) — нет, команды запуска консольной программы (типа python manage.py my_cron_script) — тоже нет… Неужели невостребовано? Надеюсь, в новых версиях появится.

[Sergei_Erjemin]

А у меня не заработало… Все установилось, вызов ./manage.py migrate изменился, но, блин, новые или удаленные поля в модели не заставляют базу перестроится… Говорит в консолке: "./manage.py migrate"… и самое обидное, что это тоже не помогает.

Я, конечно, совсем чайник в Джанге, но хочется понять что не так делаю?

[alekseyshavrak]

Не обязательно сливать svn'ом код утилиты, можно проще через ssh — pip install south