Comments 33
South для django работает примерно так-же, только миграции хранятся не в нечитабельном богопротивном XML а в питоньих файлах, что достаточно удобно. Ну и детект изменений есть.
А до этого я юзал какой-то SQL Diff на джаве кем-то из яндекса нарытый где-то на просторах интернета.
Делал 2 sql в одну и в обратную сторону и ручками их накатывал.
Тоже опыт хороший был.
только миграции хранятся не в нечитабельном богопротивном XML а в питоньих файлах

Ничего что из-за этого эту утилиту можно спокойно использовать в рамках любого проекта, а South только в рамках django? Опять же всегда интересовало что же такого нечетабельного и богопротивного в XML. Особенно учитывая наличие возможности автоматической валидации данных как на выходе так и на входе.
Нене, я не говорю что утилита не нужна — просто делюсь опытом. Сравнение различных решений всегда полезно.
А XML нечИтабелен своей избыточностью. Я в последнее время по возможности использую yaml — выглядит гораздо удобнее.
Нене, я не говорю что утилита не нужна — просто делюсь опытом. Сравнение различных решений всегда полезно.

База может обладать существенно большим временем жизни. И я бы лучше держал изменения и проектирование базы отдельно от приложения.

XML нечИтабелен своей избыточностью. Я в последнее время по возможности использую yaml — выглядит гораздо удобнее.

А вы его не читайте, это все же формат для машинного обмена данными, а не для чтения человеком. У yaml я не припомню автоматической валидации. Так что если пришел мусор, то отсечь его не получится.

Опять же для Liquibase есть плагин к эклипсу который упрощает жизнь.
База может обладать существенно большим временем жизни. И я бы лучше держал изменения и проектирование базы отдельно от приложения.

Зачем? Ченжлог гораздо нагляднее, причем это довольно странно соотносится с вашим «А вы его не читайте».

У yaml я не припомню автоматической валидации. Так что если пришел мусор, то отсечь его не получится.

Вы сейчас про формат или про структуру?
Зачем? Ченжлог гораздо нагляднее, причем это довольно странно соотносится с вашим «А вы его не читайте».

А затем, что лучше сначала спроектировать СУБД, а уже заниматься реализацией в приложении. Какой именно ченжлог?

Вы сейчас про формат или про структуру?

Про структуру.
XML хорош тем, что он позволяет
1. Автоматически валидировать по схеме
2. Автодополнение в IDE на основе, опять же, схемы данных.

После этого топика опубликую Tips & Tricks liquibase, и использование XML, а не DSL там — одна из хороших практик.
Ну ямл или жсон тоже можно по схеме валидировать.
www.kuwata-lab.com/kwalify/

За автодополнение не скажу — привычки программировать на XML не имею :)
Вот именно для этого автодополнение и нужно! Для ленивых, не имеющих привычки программистов (типа меня)
Я не хочу лезть в документацию, наоборот, я встаю внутрь любого тэга, жму, Ctrl+Space и вижу какие элементы мне разрешены в этом месте!
Эта хернь поддерживает xml, yaml, json и plain sql. Не нужно так ругать ее, это шикарная штука, если бы не была написана на java =) Это ограничивает круг пользователей.
На чем-то ее же надо было создателям написать) Да чтоб еще и работало легко на всех платформах.

Какую современную утилиту не возьми, мне приходится устанавливать или perl, или python, или node.js, или ruby, или java…
В итоге, я просто поставил однажды все это и больше у меня голова не болит.
Вам как человеку связанному с java, проблем эта платформа не придает, а лишь добавляет удобств, а мне как человеку у которого по нужде уже стоит питон и руби, ставить лишнюю платформу как минимум дискомфортно =)
Слышал от коллег, что на каждое изменение таблицы он выполняет отдельный запрос. Т.е. если добавляем две колонки и liquibase выполнит два alter запроса. Это так?
Я не проверял такие подробности. Это имеет значение?
Можно включить логгирование всех запросов к базе и увидеть, что и как, если очень надо будет.
Конечно имеет. Если таблица большая и весит несколько гигов, то делать два запроса вместо одного — это жесть :)
Если таблица большая и весит несколько гигов, и вы работаете с СУБД, которая не умеет моментально добавлять nullable стольбы или удалять их без перелопачивания всей таблицы и остановки работы (mysql — как раз не умеет), то делать любой альтер, даже одиночный, — это жесть. :)
Менять слой СУБД для миграций? Довольно странно и невыполнимо для большинства проектов.
Предполагаю, здесь возможны варианты типа создания таблицы рядом, с данными и нужной колонкой, а потом переименованием… Но это довольно грязный хак.
Не пробовал FlyWay, ничего о нем еще не слышал…
Liquibase довольно распространен в Java-мире, поэтому я с ним знаком.
FlyWay тоже, как ни странно, распространён в джава мире, даже плагин для мавена есть.
Более того, в случае постгреса он поддерживает нативные функции которые liquibase не поддерживает.
Мы сравнивали когда то. Liqubase выглядит универсальным комбайнов по сравнению с FlyWay. У Liqubase больше возможностей. Решающим фактором для нас оказалось то, что в Liqubase можно писать changesets не зависящие от базы данных.
Бесит что несмотря на наличие Rollback-а нельзя просто откатить changeset. Ибо надо делать тег, либо откатываться назад по истории. Непродумано короче. Но лучше вроде как ничего нет.
А она может генерить из существующей базы файлы с чейнджсетами/чейнджлогами? И как это сделать если да? Документация у него не ахти, опций куча, я пытался что-то хоть сделать, но увы…
Да, я видел, моя ошибка была в том что я пытался использовать json =) Сходу оно так просто не работает)
Кстати, раз уж пошло такое дело еще спрошу один вопрос =) А может ли она генерить разницу между файлом с миграцией и текущим состоянием бд, ато я нашел лишь генерацию текущего состояния базы, а мне нужна именно разница между предидущей ревизией.
Это я тоже видел, и даже пытался использовать, но разве он не выдает разницу между двумя подключениями? Я хотел именно между текущим соединением и ченджсетами в вайле :(
Only those users with full accounts are able to leave comments. Log in, please.