Comments 33
South для django работает примерно так-же, только миграции хранятся не в нечитабельном богопротивном XML а в питоньих файлах, что достаточно удобно. Ну и детект изменений есть.
А до этого я юзал какой-то SQL Diff на джаве кем-то из яндекса нарытый где-то на просторах интернета.
Делал 2 sql в одну и в обратную сторону и ручками их накатывал.
Тоже опыт хороший был.
Делал 2 sql в одну и в обратную сторону и ручками их накатывал.
Тоже опыт хороший был.
только миграции хранятся не в нечитабельном богопротивном XML а в питоньих файлах
Ничего что из-за этого эту утилиту можно спокойно использовать в рамках любого проекта, а South только в рамках django? Опять же всегда интересовало что же такого нечетабельного и богопротивного в XML. Особенно учитывая наличие возможности автоматической валидации данных как на выходе так и на входе.
Нене, я не говорю что утилита не нужна — просто делюсь опытом. Сравнение различных решений всегда полезно.
А XML нечИтабелен своей избыточностью. Я в последнее время по возможности использую yaml — выглядит гораздо удобнее.
А XML нечИтабелен своей избыточностью. Я в последнее время по возможности использую yaml — выглядит гораздо удобнее.
Нене, я не говорю что утилита не нужна — просто делюсь опытом. Сравнение различных решений всегда полезно.
База может обладать существенно большим временем жизни. И я бы лучше держал изменения и проектирование базы отдельно от приложения.
XML нечИтабелен своей избыточностью. Я в последнее время по возможности использую yaml — выглядит гораздо удобнее.
А вы его не читайте, это все же формат для машинного обмена данными, а не для чтения человеком. У yaml я не припомню автоматической валидации. Так что если пришел мусор, то отсечь его не получится.
Опять же для Liquibase есть плагин к эклипсу который упрощает жизнь.
База может обладать существенно большим временем жизни. И я бы лучше держал изменения и проектирование базы отдельно от приложения.
Зачем? Ченжлог гораздо нагляднее, причем это довольно странно соотносится с вашим «А вы его не читайте».
У yaml я не припомню автоматической валидации. Так что если пришел мусор, то отсечь его не получится.
Вы сейчас про формат или про структуру?
Судя по сайту, Liquibase поддерживает yaml а еще и json.
XML хорош тем, что он позволяет
1. Автоматически валидировать по схеме
2. Автодополнение в IDE на основе, опять же, схемы данных.
После этого топика опубликую Tips & Tricks liquibase, и использование XML, а не DSL там — одна из хороших практик.
1. Автоматически валидировать по схеме
2. Автодополнение в IDE на основе, опять же, схемы данных.
После этого топика опубликую Tips & Tricks liquibase, и использование XML, а не DSL там — одна из хороших практик.
Ну ямл или жсон тоже можно по схеме валидировать.
www.kuwata-lab.com/kwalify/
За автодополнение не скажу — привычки программировать на XML не имею :)
www.kuwata-lab.com/kwalify/
За автодополнение не скажу — привычки программировать на XML не имею :)
На стандарт это мало похоже. А у xml это дело стандартизировано.
Вот именно для этого автодополнение и нужно! Для ленивых, не имеющих привычки программистов (типа меня)
Я не хочу лезть в документацию, наоборот, я встаю внутрь любого тэга, жму, Ctrl+Space и вижу какие элементы мне разрешены в этом месте!
Я не хочу лезть в документацию, наоборот, я встаю внутрь любого тэга, жму, Ctrl+Space и вижу какие элементы мне разрешены в этом месте!
Эта хернь поддерживает xml, yaml, json и plain sql. Не нужно так ругать ее, это шикарная штука, если бы не была написана на java =) Это ограничивает круг пользователей.
Слышал от коллег, что на каждое изменение таблицы он выполняет отдельный запрос. Т.е. если добавляем две колонки и liquibase выполнит два alter запроса. Это так?
Я не проверял такие подробности. Это имеет значение?
Можно включить логгирование всех запросов к базе и увидеть, что и как, если очень надо будет.
Можно включить логгирование всех запросов к базе и увидеть, что и как, если очень надо будет.
Конечно имеет. Если таблица большая и весит несколько гигов, то делать два запроса вместо одного — это жесть :)
Если таблица большая и весит несколько гигов, и вы работаете с СУБД, которая не умеет моментально добавлять nullable стольбы или удалять их без перелопачивания всей таблицы и остановки работы (mysql — как раз не умеет), то делать любой альтер, даже одиночный, — это жесть. :)
А вы не пробовали/сравнивали с FlyWay?
Не пробовал FlyWay, ничего о нем еще не слышал…
Liquibase довольно распространен в Java-мире, поэтому я с ним знаком.
Liquibase довольно распространен в Java-мире, поэтому я с ним знаком.
Мы сравнивали когда то. Liqubase выглядит универсальным комбайнов по сравнению с FlyWay. У Liqubase больше возможностей. Решающим фактором для нас оказалось то, что в Liqubase можно писать changesets не зависящие от базы данных.
Бесит что несмотря на наличие Rollback-а нельзя просто откатить changeset. Ибо надо делать тег, либо откатываться назад по истории. Непродумано короче. Но лучше вроде как ничего нет.
А она может генерить из существующей базы файлы с чейнджсетами/чейнджлогами? И как это сделать если да? Документация у него не ахти, опций куча, я пытался что-то хоть сделать, но увы…
Может. С доками у библиотеки все нормально.
www.liquibase.org/documentation/generating_changelogs.html
www.liquibase.org/documentation/generating_changelogs.html
Да, я видел, моя ошибка была в том что я пытался использовать json =) Сходу оно так просто не работает)
Кстати, раз уж пошло такое дело еще спрошу один вопрос =) А может ли она генерить разницу между файлом с миграцией и текущим состоянием бд, ато я нашел лишь генерацию текущего состояния базы, а мне нужна именно разница между предидущей ревизией.
Sign up to leave a comment.
Управление миграциями БД с Liquibase