Comments 34
Как хорошо с hibernate.
-5
мне больше нравится db4o, сразу объектная БД и с LINQ в .NET дружит (т.е. запросы к ней поддерживаются синтаксисом языка, в отличие от Hibernate)
0
Как будто Hibernate умеет обновлять схему. Те же проблемы.
0
Что значит «как будто?
0
А что, умеет? hibernate.hbm2ddl.auto = update не считается, так как оно умеет только добавлять новые поля. Или уже научилось менять и удалять?
0
Почему же не считается? Он приводит схему базы к такому виду, чтобы маппинги работали. А на менять и удалять есть create-drop.
0
Потому что после update получаются всякие безобразия. То not-null поле из базы не удалилось и вставка не работает, то размер поля сменился и иногда что-нибудь падает. Особенно напрягает слово иногда, так как про то, что схема могла измениться, к этому моменту уже забываешь.
В общем, update штука ошибкоопасная, хоть и полезная в процессе разработки. Для production придётся менять схему вручную или разрабатывать автомигратор a-la south.
В общем, update штука ошибкоопасная, хоть и полезная в процессе разработки. Для production придётся менять схему вручную или разрабатывать автомигратор a-la south.
0
У Джанго, конечно, не все хорошо в плане обновления схемы, но и не так плохо, как вы описываете.
И схема будет обновлена.
Есть, правда, и огромный недостаток, который не позволяет выполнять команду на продакш сервере — вся данные из таблиц приложения очищаются.
А вобще, за инструмент огромное спасибо! Сам некоторое время столкнулся с такой проблемой — пока что делал как написано в мануале Джанго — писал руками альтеры =)
python manage.py reset [appname]
И схема будет обновлена.
Есть, правда, и огромный недостаток, который не позволяет выполнять команду на продакш сервере — вся данные из таблиц приложения очищаются.
А вобще, за инструмент огромное спасибо! Сам некоторое время столкнулся с такой проблемой — пока что делал как написано в мануале Джанго — писал руками альтеры =)
+3
ну, так резет ведь убивает содержимое базы, а это даже при начальной разработке сильно мешает — приходится заново 'рыбу' (тестовые данные) генерить
+1
btw, я бы побоялся использовать South «как есть» на продакшене — мало ли, какую херню он сгенерит
неплохо бы там сделать режим предпросмотра SQL statements при миграции…
неплохо бы там сделать режим предпросмотра SQL statements при миграции…
+3
Я использую deseb(http://code.google.com/p/deseb/) и не имею никакого гемороя.
+5
UFO just landed and posted this here
Выбирал из south и django-evolution.
Остановился на последнем, т.к. можно вручную миграции не описывать, ну и идеологии немножко разные у них.
Остановился на последнем, т.к. можно вручную миграции не описывать, ну и идеологии немножко разные у них.
+3
туда же django evolution
+3
Так есть же deseb где не надо руками писать миграции, а он сам сравнивает модель со структурой бд.
+1
UFO just landed and posted this here
Слишком наворочено, решение добавляет лишних уровней абстракции.
Я обхожусь скриптом, который удаляет все таблицы, запускает syncdb и загружает начальные данные (fixtures).
Пример CMD-скрипта:
Единственный минус — надо практически вручную вносить изменения в fixtures, но использовать fixtures — это завсегда полезная практика.
Я обхожусь скриптом, который удаляет все таблицы, запускает 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 — это завсегда полезная практика.
+1
Всегда пользовался django-evolution. Уже даже приспособился к некоторым его «особенностям». Было бы классно, если бы в самой джанге был полноценный мигратор, как в Ruby on Rails, к примеру.
0
Автор!!! КОНКРЕТНОЕ БОЛЬШОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБИЩЕ!!!
п.с. начинающий питоно-дажнгер прогер столкнувшийся с такойже проблемой.
п.с. начинающий питоно-дажнгер прогер столкнувшийся с такойже проблемой.
+1
Вообще, странно оно как-то… Джанге уже несколько лет от роду, а встроенного мигратора (хоть какого-то, хоть ручного) — нет, команды запуска консольной программы (типа python manage.py my_cron_script) — тоже нет… Неужели невостребовано? Надеюсь, в новых версиях появится.
0
А у меня не заработало… Все установилось, вызов
Я, конечно, совсем чайник в Джанге, но хочется понять что не так делаю?
./manage.py migrate
изменился, но, блин, новые или удаленные поля в модели не заставляют базу перестроится… Говорит в консолке: "./manage.py migrate"… и самое обидное, что это тоже не помогает. Я, конечно, совсем чайник в Джанге, но хочется понять что не так делаю?
0
Не обязательно сливать svn'ом код утилиты, можно проще через ssh — pip install south
0
Sign up to leave a comment.
South — новый клёвый syncdb