Pull to refresh

Comments 34

мне больше нравится db4o, сразу объектная БД и с LINQ в .NET дружит (т.е. запросы к ней поддерживаются синтаксисом языка, в отличие от Hibernate)
Пока у вас не появится более менее сложные запросы на большие куски данных — всё будет хорошо. Это же odbms.
Как будто Hibernate умеет обновлять схему. Те же проблемы.
Что значит «как будто?
А что, умеет? hibernate.hbm2ddl.auto = update не считается, так как оно умеет только добавлять новые поля. Или уже научилось менять и удалять?
Почему же не считается? Он приводит схему базы к такому виду, чтобы маппинги работали. А на менять и удалять есть create-drop.
Потому что после update получаются всякие безобразия. То not-null поле из базы не удалилось и вставка не работает, то размер поля сменился и иногда что-нибудь падает. Особенно напрягает слово иногда, так как про то, что схема могла измениться, к этому моменту уже забываешь.

В общем, update штука ошибкоопасная, хоть и полезная в процессе разработки. Для production придётся менять схему вручную или разрабатывать автомигратор a-la south.
Не понял — вы в продакшен хотите использовать какие-то вариации на тему обновления схемы? С ума сошли?
А вы считаете, что в продакшн схема никогда не должна меняться?
У Джанго, конечно, не все хорошо в плане обновления схемы, но и не так плохо, как вы описываете.
python manage.py reset [appname]
И схема будет обновлена.
Есть, правда, и огромный недостаток, который не позволяет выполнять команду на продакш сервере — вся данные из таблиц приложения очищаются.

А вобще, за инструмент огромное спасибо! Сам некоторое время столкнулся с такой проблемой — пока что делал как написано в мануале Джанго — писал руками альтеры =)
ну, так резет ведь убивает содержимое базы, а это даже при начальной разработке сильно мешает — приходится заново 'рыбу' (тестовые данные) генерить
UFO just landed and posted this here
Fixtures частично спасают ситуацию.
btw, я бы побоялся использовать South «как есть» на продакшене — мало ли, какую херню он сгенерит

неплохо бы там сделать режим предпросмотра SQL statements при миграции…
а зачем менять бд на продакшене? :) по-идее все должно быть уже стабильно и вноситься маленькие фиксы :)
Я использую deseb(http://code.google.com/p/deseb/) и не имею никакого гемороя.
UFO just landed and posted this here
а зачем наследоваться от User?

не имел таких проблем, на 1.0 я не тестировал, проект крутится на предыдущей версии
но в целом отличная штука, проблем не имею с ним
UFO just landed and posted this here
Всё пофиксили, замечательно работает.
В смысле, что с Django 1.0 работает… с вашей проблемой не сталкивался.
Выбирал из south и django-evolution.
Остановился на последнем, т.к. можно вручную миграции не описывать, ну и идеологии немножко разные у них.

я тоже на django-evolution остановился
Так есть же deseb где не надо руками писать миграции, а он сам сравнивает модель со структурой бд.
UFO just landed and posted this here
Слишком наворочено, решение добавляет лишних уровней абстракции.
Я обхожусь скриптом, который удаляет все таблицы, запускает 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 — это завсегда полезная практика.
Всегда пользовался django-evolution. Уже даже приспособился к некоторым его «особенностям». Было бы классно, если бы в самой джанге был полноценный мигратор, как в Ruby on Rails, к примеру.
Автор!!! КОНКРЕТНОЕ БОЛЬШОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБИЩЕ!!!

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

Я, конечно, совсем чайник в Джанге, но хочется понять что не так делаю?
Не обязательно сливать svn'ом код утилиты, можно проще через ssh — pip install south
Sign up to leave a comment.

Articles