01/4: Что такое deseb.
Вспоминаю, что когда-то я обещал писать про django.
Сегодняшняя тема — эволюция баз данных для django.
Я — один из двух создателей deseb.
deseb — это Django External Schema Evolution Branch, то есть инструмент для эволюции баз данных для django. Да, юные любители ruby on rails, это практически ваши миграции, только с более простым DSL и конструирующиеся автоматически по изменениям модели.
Ну а тем, кто с rails не знаком, расскажу поподробнее.
Основа django — модели. Обычно они находятся в файлах models.py в разных папках внутри проекта. deseb умеет сравнивать содержимое моделей и текущую схему базы данных, и вносить в эту схему изменения. Таким образом, программист django вообще может не знать sql, или же изучать sql, глядя на вывод django и deseb, но никогда не писать sql самому. Наконец-то! :)
Сообразительные, но малознакомые с django, спросят — а как же переименование?
Как deseb поймет, что столбец или таблицу нужно переименовать? Конечно, он и не поймёт, пока вы не добавите полям и таблицам для переименования дополнительный аттрибут aka=… для указания их старых имён! Вот из-за этого аттрибута и пришлось сделать deseb внешним относительно django.
Ссылки по теме:
главная страница проекта — http://deseb.googlecode.com/
подробное рассмотрение миграций для django: http://code.djangoproject.com/wiki/SchemaEvolution
Проект находится в альфа-статии. Текущие хорошо поддерживаемые базы данных — postgresql и mysql. Плохо поддерживаемый — sqlite.
Я знаю несколько имеющихся мелких проблем, однако, скорее всего, они будут пребывать в состоянии “не дошли руки”, пока вы мне не поможете.
С радостью и очень быстро, скорее всего в тот же день, приму и закоммичу багфиксы ;)
Сегодняшняя тема — эволюция баз данных для django.
Я — один из двух создателей deseb.
deseb — это Django External Schema Evolution Branch, то есть инструмент для эволюции баз данных для django. Да, юные любители ruby on rails, это практически ваши миграции, только с более простым DSL и конструирующиеся автоматически по изменениям модели.
Ну а тем, кто с rails не знаком, расскажу поподробнее.
Основа django — модели. Обычно они находятся в файлах models.py в разных папках внутри проекта. deseb умеет сравнивать содержимое моделей и текущую схему базы данных, и вносить в эту схему изменения. Таким образом, программист django вообще может не знать sql, или же изучать sql, глядя на вывод django и deseb, но никогда не писать sql самому. Наконец-то! :)
Сообразительные, но малознакомые с django, спросят — а как же переименование?
Как deseb поймет, что столбец или таблицу нужно переименовать? Конечно, он и не поймёт, пока вы не добавите полям и таблицам для переименования дополнительный аттрибут aka=… для указания их старых имён! Вот из-за этого аттрибута и пришлось сделать deseb внешним относительно django.
Ссылки по теме:
главная страница проекта — http://deseb.googlecode.com/
подробное рассмотрение миграций для django: http://code.djangoproject.com/wiki/SchemaEvolution
Проект находится в альфа-статии. Текущие хорошо поддерживаемые базы данных — postgresql и mysql. Плохо поддерживаемый — sqlite.
Я знаю несколько имеющихся мелких проблем, однако, скорее всего, они будут пребывать в состоянии “не дошли руки”, пока вы мне не поможете.
С радостью и очень быстро, скорее всего в тот же день, приму и закоммичу багфиксы ;)
Comments
Я, кстати, недавно пробовал его. Самая напряжная штука — крайняя вербозность вывода… :-)
А я, к сожалению, должен согласиться с джанговскими коммиттерами: атрибут “aka” — это главная и фатальная вещь, которая убивает всю эту идею. Ему нечего делать внутри модели, потому что модель от него ничего не получает, это внешняя информация. И он сам по себе не версионируется… Мне гораздо ближе архитектура http://code.google.com/p/django-evolution/
По поводу вербозности: Есть опция —dont-notify, которая возможно скоро станет умолчательной.
По поводу aka: Это Derek держался за идею aka до последнего. Я был против. Мне тоже не нравится, что из-за этого aka возникает дополнительная зависимость. deseb нельзя убрать и нужно импортировать. неверсионируемый. да и действительно, не место ему там. Я с лёгкостью могу добавить информацию, заменяющую aka, в command line команды и в создаваемые версионируемые файлы, и займусь этим после того, как расправлюсь с оставшимися багами. Мне не нравится архитектура django-evolution, потому что если информация в базе не будет соответствовать модели и схеме, то django-evolution будет бесполезен и чинить придётся руками. Это как раз то, чего хотелось бы избежать. Ну и mergeability-scalability у него низкая за счёт использования базы данных. Плиз, поправь меня если я в чем-то ошибся. Другой возможный бонус от использования deseb — получение умного inspectdb.
Ну наконец-то, Юрец что-то выдал :)
Юрец выдавал и раньше, только редко об этом писал.
Ну я как раз об этом и говорю :)
Очень хотелось бы поддержку many2many-полей т.к. они часто добавляются и приходится пересоздавать все таблицы.
а разве она не работает? : вообще, many2many поле — это отдельная таблица. даже syncdb их должен создавать и удалять уметь.
Поддержка many2many теперь полностью работает.
Очень круто, спасибо :) Постоянно пользуюсь deseb’ом, теперь не буду париться по поводу изменение в m2m
А если проект состоит из нескольких приложений, причем модель одного приложения связана с моделью другого посредством m2m или ForeignKey — есть ли возможность прикрутить deseb?
Что думаете о South (http://south.aeracode.org/)?
South — отличная вещь для ручного управления миграциями. Читаем: automatic migration creation While you may find the idea of converting all of your schema into migrations worrying, don’t worry — we didn’t like the idea either. That’s why South not only makes and correctly numbers skeleton migrations for you, it does the same for model definitions, scanning them and writing a complete creation migration for you.
я делаю вещь для автоматического управления миграциями. Всё-таки у нас не рельсы, в программе есть модель БД.
кстати, бэкэнд готов на 100%, я с South поговорю, может, они его себе всё-таки прикрутят, несмотря на этот параграф ;)