Публикации с меткой «south»

Административный интерфейс джанго позволяет настраивать права доступа к объектам различных приложений. Для любой модели любого приложения вы можете разрешить пользователю три действия: добавлять новые объекты, редактировать и удалять существующие объекты.

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

Последние 15 недель мы активно работали над проектом «Стиллион», первым нашим мейнстрим-проектом, написанным на Django. Был приобретен интересный опыт, которым мы хотели бы поделиться с сообществом.
Статья, прежде всего, будет интересна новичкам в Django.

Перевод отличной статьи с DjangoAdvent. Описывает различные Django Best Practice.

Kevin Fricovsky создатель проекта Mingus, который возводит в идеал идею реиспользуемых приложений. Мингус состоит только из них, и объединяя более 30 приложений реализует полноценный движок блога.

Автор затрагивает такие вещи как local_settings, DB migration, live settings и другие.

В прошлый раз мы остановились на том, что запустили django на машине разработчика. Использование virtualenv оставим на самостоятельное рассмотрение. А вот pip мы все-таки установим. Тем более, что у нас в проекте уже лежит пустой файл requirements.txt - файл формата pip, со списком приложений, необходимых для нашего проекта. Кстати, пора в него уже прописать:
Django==1.2.1

Далее, качаем pip, разархивируем, устанавливаем:
pip-0.7.2>python setup.py install

Теперь перейдем к теме.

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

Основные особенности, которые отмечают разработчики:

* отслеживание изменений в модели и создание миграций
* независимость от движков БД (заявлена поддержка 5 разных типов БД)
* создание миграций только для выбранного приложения (application)
* сообщение о возможных конфликтах при комите миграций от других разработчиков

Далее:

Устанавливаем South
>C:\Python26\Scripts\pip.exe install South
или
#pip install South

Вы уже наверное заметили, что у меня две машины разработчика. Одна под windows, другая Kubuntu, поэтому в будущем буду выводить консольные команды той системы, в которой работаю, поскольку они аналогичны.

Добавляем south в INSTALLED_APPS и делаем syncdb (пробуем из gui).



Так как по умолчанию в INSTALLED_APPS прописано несколько стандартных приложений, в том числе django.contrib.auth, поэтому в консоли выполним создание суперпользователя сайта (первый запуск syncdb).

South применяется отдельно для каждого приложения в проекте, а так как у нас нет приложений, то пока настройку South можно считать законченной (подробнее по вышеприведенным ссылкам или в документации). Плюс, мы еще вернемся к обсуждению South позже.

South будет резделён на 2 части, и одна из них должна войти в состав Django. Также в посте есть ссылка на презентацию Эндрю с djangocon.eu в pdf и как видео.

Для тех кто не знает South — это система миграции структуры базы данных или самих данных для Django/Джанго. До версии 0.7 она была сыровата, но со вчерашним выходом версии 0.7 наконец South довели до ума и даже добавили поддержку нескольких баз, появившуюся в Django 1.2 и alfa-поддержку Oracle. В том числе поправлен досадный баг, делавший невозможной миграцию many-to-many fields.

Отмечу, что есть конечно и другие системы миграции для Django, типа deseb или django-evolution, но или проекты заброшены или нет поддержки распространенных баз данных. Так что South на данный момент определенно мэйнстрим. Итак, зачем и как использовать South?

Главное применение, которое я вижу — это миграция структуры базы данных и самих данных на боевой базе, то есть система находиться в эксплуатации и периодически, что то меняется в базе: добавили новое поле или удалили старое, может поменялись значения в редко меняемых справочных таблицах и т.д.

Для первого нашего Django-проекта я решил использовать South, чтобы меньше заморачиваться с модификациями БД (например, выполнять их автоматически при деплойменте). Всё здорово, но вот в версии 0.5 была подлая "засада" - South не совсем корректно понимал вариант, когда default для полей задавался через callable. Приходилось ручками править определение поля, создавать миграцию, а потом исправлять поле на первоначальный вариант. Однако вышла версия 0.6 и там это было исправлено. "Здорово" подумал я, но не тут-то было :)
Проблема возникла в обновлении версии пакета, который был поставлен в virtualenv через pip. В документации к pip данный вопрос вообще никак не освещается. Путём гугления обнаружилась опция --upgrade, только вот указывать для файла с зависимостями оказалось неверным вариантом, потому как через зависимости тянулся почему-то злосчастный PIL, некорректно устанавливающийся.
Пришлось делать апгрейд пакета отдельно ручками как

pip -E . install --upgrade South

Но в site-packages остаются "концы" от старой версии 0.5, поэтому их пришлось ручками стереть.
Python, конечно, неплохой язык, но вот всё чаще вспоминаются слова dmz про package hell, и это далеко не радует.