svn + бд. Как синхронизировать в продакшене?
Я бы наплодил энцать бд с названиями коррелирующими с названиями тегов, хранил бы название тега в какомнить конфиге параметром, и в зависимости от этого параметра вычислял бы урл коннекта к бд в коде.
ЗЫ Какие-то у тебя бранчеобразные теги =)
ЗЫ Какие-то у тебя бранчеобразные теги =)
Конечно можно хранить все изменения в маленьких файликах (пусть 1.1, 1.2, 1.3)отдельно от svn, но это всё равно ручной режим, т.к. после разных мержей придём к тому, что необходимо применить, например 1.1 и 1.3, а 1.2 применять не нужно.можно попробовать обернуть svn switch в ant или make
я бы наплодил sql запросов, который конвертят базу из одного вида в другой.
какой смысл это автоматизировать?
есть предположение, что, у вас у каждого разработчика свой личный сервер БД -
но тут надо подумать оправдано ли это?
уже в нескольких проектах работал по такой схеме, что сервер один на всех,
а все изменения между ветками хранятся ввиде sql в svn и накатываются вручную ответственным за БД человеком.
и не особо геморно и за целостность данных все спокойны.
есть предположение, что, у вас у каждого разработчика свой личный сервер БД -
но тут надо подумать оправдано ли это?
уже в нескольких проектах работал по такой схеме, что сервер один на всех,
а все изменения между ветками хранятся ввиде sql в svn и накатываются вручную ответственным за БД человеком.
и не особо геморно и за целостность данных все спокойны.
по идее если структуру базы изменяют не просто так 
то в новой версии базы появляется возможность хранить что-то дополнительное. то есть если ты переключишься с 2.0 на 1.0 а потом обратно и при этом будешь и базу конвертить, то ты потеряешь эти самые дополнительные данные. или там у вас такой проект что базу можно в любой момент потранкейтить? =)
или ты просто про тестирование программы, которое можно над голой базой делать? тогда кажется достаточно вместе с каждой версией кода хранить нужную ему структуру базы, безо всяких конверторов одной версии в другую.
то в новой версии базы появляется возможность хранить что-то дополнительное. то есть если ты переключишься с 2.0 на 1.0 а потом обратно и при этом будешь и базу конвертить, то ты потеряешь эти самые дополнительные данные. или там у вас такой проект что базу можно в любой момент потранкейтить? =)или ты просто про тестирование программы, которое можно над голой базой делать? тогда кажется достаточно вместе с каждой версией кода хранить нужную ему структуру базы, безо всяких конверторов одной версии в другую.
В django есть syncdb и reset. первое создаёт таблицу, если ничего не было, а второе удаляет таблицу.
Т.е. всё, что я писал имеет смысл тогда, когда хочется работать с данными.
Для данных разработчики django придумали fixtures (не знаю, как это по-русски нормально) - это дамп базы в xml, json или ещё разных форматах.
Проблема в том, что эти fixtures при добавлении нового поля не загружаются.
От этого с ними работать не хочется. И на ум приходит мысль не удалять/создавать заново, а просто alter'ом добавить нужные поля с дефолтными значениями.
В статегическом смысле есть ещё одна задумка. При введении новой версии в продакшен и каком-то неблагоприятном поведении, всегда есть способ сделать switch stable-version. Т.е. переключиться одной командой.
При изменении структуры БД такой фокус конечно не проходит.
Я понимаю, что качество данных может несколько пострадать, например, когда некоторые поля примут дефолтные значения (особенно если учесть, что switch переключает версию кода, а не данных но это меньшее зло по сравнению с тем, что пизданётся всё.
Пример, который у меня созрел.
время Ч.
есть table1
id
name
age
Есть какой-то код, который с этой таблицей работает.
время Ч+1.
появляется table2
id
address
city
Появляется код, которые регистрирует некоторых жителей по адресам.
время Ч+2.
(вводится закон об обязательной регистрации)
и человек, который следит за таблицами, решает, что table1 и table2 - это роскошь.
Удаляет table2, все данные оттуда переводит в table1, которая становится
id
name
age
address
city
вот этот последний шаг, что называется, сжигает мосты. Теперь, если что-нибудь не будет работать, нельзя будет вернуться к менее функциональной проверенной годами версии.
У меня вертится такое решение.
есть папочка db-atoms.
В ней каждый файл содержит изменение и откат изменения.
Дальше при switch c ревизии, например N до M, svn сравнивает список файлов, и те, которые появлись применяет, а те, которые исчезли - откатывает.
Возможно, что там будут некоторые проблемы, связанные с зависимостями и т.д. Но я и спрашиваю, чтобы понять, есть ли решения такой задачи.
Т.е. всё, что я писал имеет смысл тогда, когда хочется работать с данными.
Для данных разработчики django придумали fixtures (не знаю, как это по-русски нормально) - это дамп базы в xml, json или ещё разных форматах.
Проблема в том, что эти fixtures при добавлении нового поля не загружаются.
От этого с ними работать не хочется. И на ум приходит мысль не удалять/создавать заново, а просто alter'ом добавить нужные поля с дефолтными значениями.
В статегическом смысле есть ещё одна задумка. При введении новой версии в продакшен и каком-то неблагоприятном поведении, всегда есть способ сделать switch stable-version. Т.е. переключиться одной командой.
При изменении структуры БД такой фокус конечно не проходит.
Я понимаю, что качество данных может несколько пострадать, например, когда некоторые поля примут дефолтные значения (особенно если учесть, что switch переключает версию кода, а не данных но это меньшее зло по сравнению с тем, что пизданётся всё.
Пример, который у меня созрел.
время Ч.
есть table1
id
name
age
Есть какой-то код, который с этой таблицей работает.
время Ч+1.
появляется table2
id
address
city
Появляется код, которые регистрирует некоторых жителей по адресам.
время Ч+2.
(вводится закон об обязательной регистрации)
и человек, который следит за таблицами, решает, что table1 и table2 - это роскошь.
Удаляет table2, все данные оттуда переводит в table1, которая становится
id
name
age
address
city
вот этот последний шаг, что называется, сжигает мосты. Теперь, если что-нибудь не будет работать, нельзя будет вернуться к менее функциональной проверенной годами версии.
У меня вертится такое решение.
есть папочка db-atoms.
В ней каждый файл содержит изменение и откат изменения.
Дальше при switch c ревизии, например N до M, svn сравнивает список файлов, и те, которые появлись применяет, а те, которые исчезли - откатывает.
Возможно, что там будут некоторые проблемы, связанные с зависимостями и т.д. Но я и спрашиваю, чтобы понять, есть ли решения такой задачи.
Я хочу добиться того, чтобы svn switch (или быть может какая-то другая команда) меняла бы не только код, но и соотсветсвенно этому коду структуру БД.По-моему куча лишней возни.
Пример
/tag/1.0 - какая-то версия приложения.
/tag/2.0 - другая версия с изменённой структурой БД.
svn switch .../tag/2.0 - приведёт к тому, что приложение перестанет работать, т.к. код 2.0 не работает со структурой 1.0 БД.
А что делать если ты в новой версии (2.0) удалил из таблицы колонку с данными? "просто так" они ниоткуда не появятся.
Нормальный способ — заводить отдельную БД для каждой ветки.
Но можно помучаться и сделать так:
— автоматический upload данных в версию 1.0
— миграции в каждую следующую версию (кстати, не знаю какая из тулзей удобнее).
— в каждой ветке после switch дропаешь БД, аплоадишь в нее данные и накатываешь все-все миграции в этой ветке. Хочется верить что эти миграции не особо глюкавые.
вот этот последний шаг, что называется, сжигает мосты. Теперь, если что-нибудь не будет работать, нельзя будет вернуться к менее функциональной проверенной годами версии.Так ты это еще и в продакшене делать хочешь? Ну тогда это клиника :-(
Заводи отдельную ветку svn, отдельную БД, туда ручками аккуратно переливай данные, проверяй что все отлично работает (и что не было insert/update в production потом правь конфиг вебсервера и делай graceful (или kill -HUP, как там у вас принято). Еслли все хорошо — чекаут старой ветки удалишь. Если нет — легко вернешь обратно.
То, что я про продакшн говорил, не значит, что там транк и прогаю прямо там же.
Был неприятный опыт, когда сломался один малоиспользуемый модуль. Начальство матюгалось, что в жопу рюшечки, восстанавливай, как было. Учитывая, что новых данных накопилось порядочно, пришлось откатывать код и переделывать новую БД в старую с сохранением данных.
Конечно, рабочую(старую) версию БД, а лучше вместе с кодом хранить нужно, с этим-то я не спорю. Но там и данные будут старые.
Был неприятный опыт, когда сломался один малоиспользуемый модуль. Начальство матюгалось, что в жопу рюшечки, восстанавливай, как было. Учитывая, что новых данных накопилось порядочно, пришлось откатывать код и переделывать новую БД в старую с сохранением данных.
Конечно, рабочую(старую) версию БД, а лучше вместе с кодом хранить нужно, с этим-то я не спорю. Но там и данные будут старые.
Был неприятный опыт, когда сломался один малоиспользуемый модуль. Начальство матюгалось, что в жопу рюшечки, восстанавливай, как было. Учитывая, что новых данных накопилось порядочно, пришлось откатывать код и переделывать новую БД в старую с сохранением данных.Отсюда мораль: надо не "миграции" писать", а "тесты".
Простой пример: удалил из БД колонку и дописал новых данных. И хочу структуру как было. Никакая автоматика не решит правильно что тут надо делать. Это ручная работа.
Так я ж не против всё руками описать.
В смысле все алтеры и т.п.
Вопрос в том, куда эти скриптики сложить, чтобы достичь необходимого поведения.
В смысле все алтеры и т.п.
Вопрос в том, куда эти скриптики сложить, чтобы достичь необходимого поведения.
У тебя при таком подходе все изменения должны быть обратно совместимы. Так и будет?
Не очень понял вопроса.
версия 1.0 кода совместима со структурой бд 1.0, но не с бд 2.0
версия 2.0 кода совместима со структурой бд 2.0, но не с бд 1.0
при переключении 2.0 -> 1.0 -> 2.0 часть данных потеряется (какая именно часть зависит от написание скриптов с alter'ом
версия 1.0 кода совместима со структурой бд 1.0, но не с бд 2.0
версия 2.0 кода совместима со структурой бд 2.0, но не с бд 1.0
при переключении 2.0 -> 1.0 -> 2.0 часть данных потеряется (какая именно часть зависит от написание скриптов с alter'ом
С чего ты взял что у тебя всегда будет существовать преобразование из нового формата БД в старый?
Да даже если и существует — работа это ручная, и автоматикой тут пользоваться нельзя. Вместо того чтоб решать проблему по мере поступления (при тестировании пропустил багу и надо откатиться обратно) ты будешь фиксить багу "заранее" — у вас графика разработки нет?
Если багу нашли "через пару недель" значит она не критичная. Если сразу — надо переключить вебсервер обратно на работу со старой веткой svn. А БД для этого надо хранить — старую.
Да даже если и существует — работа это ручная, и автоматикой тут пользоваться нельзя. Вместо того чтоб решать проблему по мере поступления (при тестировании пропустил багу и надо откатиться обратно) ты будешь фиксить багу "заранее" — у вас графика разработки нет?
Если багу нашли "через пару недель" значит она не критичная. Если сразу — надо переключить вебсервер обратно на работу со старой веткой svn. А БД для этого надо хранить — старую.
у вас графика разработки нет
Всё вышеописанное на случай проекта, который развивается постоянно.
Если разработка под ключ - то проблем с данными нет, конечно.
почитай вот это http://www.liquibase.org/ мб поможет
В общем смотрел я смотрел и так и не понимаю: чем тебя South не устраивает?
Оставить комментарий
Phoenix
Есть структура БД (у меня mysql) и какой-то сайт(у меня на python,django. Код под svn.Я хочу добиться того, чтобы svn switch (или быть может какая-то другая команда) меняла бы не только код, но и соотсветсвенно этому коду структуру БД. (в БД могут храниться данные)
Пример
/tag/1.0 - какая-то версия приложения.
/tag/2.0 - другая версия с изменённой структурой БД.
svn switch .../tag/2.0 - приведёт к тому, что приложение перестанет работать, т.к. код 2.0 не работает со структурой 1.0 БД.
Конечно можно хранить все изменения в маленьких файликах (пусть 1.1, 1.2, 1.3)отдельно от svn, но это всё равно ручной режим, т.к. после разных мержей придём к тому, что необходимо применить, например 1.1 и 1.3, а 1.2 применять не нужно.
Какие есть решения или как можно минимизировать головную боль?
(http://habrahabr.ru/blogs/django/47004/ - здесь таже проблема c "линейным" решением)