Hibernate: hbm2ddl.auto = обновление в производстве?

Question

Можно ли запускать приложения Hibernate, настроенные с hbm2ddl.auto=update, для обновления схемы базы данных в производственной среде?

Answer 1

Нет, это небезопасно.

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

Теоретически, если обновление hbm2ddl работало в разработке, оно должно работать и в производстве. Но на самом деле это не всегда так.

Даже если все работает нормально, оно может быть неоптимальным. Администраторам платят так много по причине.

Answer 2

Мы делаем это в производстве, хотя с приложением, которое не является критически важным, и без высокооплачиваемых администраторов баз данных. Это всего лишь один меньше ручной процесс, который подвержен человеческим ошибкам - приложение может обнаружить разницу и сделать правильные вещи, плюс вы предположительно протестировали ее в различных средах разработки и тестирования.

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

Answer 3

Создатели Hibernate не рекомендуют делать это в производственной среде в своей книге "Сохранение Java в Hibernate" :

ПРЕДУПРЕЖДЕНИЕ. Мы видели, как пользователи Hibernate пытались использовать SchemaUpdate для автоматического обновления схемы производственной базы данных. Это может быстро закончиться катастрофой и не будет разрешено вашим администратором базы данных.

Answer 4

Проверьте LiquiBase XML на наличие журнала изменений. Я никогда не использовал его до этого года, но обнаружил, что его очень легко освоить и сделать управление ревизиями БД / управление миграцией / изменениями очень надежным. Я работаю над проектом Groovy / Grails, и Grails использует Hibernate для всех своих ORM (называемых «GORM»). Мы используем Liquibase для управления всеми изменениями схемы SQL, что мы делаем довольно часто, так как наше приложение развивается с новыми функциями.

По сути, вы храните XML-файл наборов изменений, которые вы продолжаете добавлять по мере развития вашего приложения. Этот файл хранится в git (или как вы используете) с остальной частью вашего проекта. Когда ваше приложение развернуто, Liquibase проверяет его таблицу изменений в БД, к которой вы подключаетесь, чтобы узнать, что уже применено, а затем разумно просто применяет все изменения, которые еще не были применены из файла. На практике он работает великолепно, и если вы используете его для всех изменений схемы, то вы можете быть на 100% уверены, что код, который вы извлекаете и разворачиваете, всегда сможет подключиться к полностью совместимой схеме базы данных.

Удивительная вещь в том, что я могу взять на своем ноутбуке совершенно чистую базу данных mysql, запустить приложение и сразу же настроить схему для меня. Это также облегчает тестирование изменений схемы, применяя их сначала к локальной dev-системе или промежуточной базе данных.

Самый простой способ начать работу с ним - это взять существующую базу данных и затем использовать Liquibase для создания исходного файла baseline.xml. Тогда в будущем вы можете просто добавить к нему и позволить liquibase взять на себя управление изменениями схемы.

http://www.liquibase.org/

Answer 5

Hibernate должен поставить заявление об отказе от использования автообновлений в prod, чтобы скрыть себя, когда люди, которые не знают, что делают, используют его в ситуациях, когда его не следует использовать.

Конечно, ситуации, когда его не следует использовать, намного превосходят те, где все в порядке.

Я годами использовал его в разных проектах, и у меня никогда не было ни одной проблемы. Это не плохой ответ, и это не ковбойское кодирование. Это исторический факт.

Человек, который говорит «никогда не делай этого в производстве», думает о конкретном наборе производственных развертываний, а именно о тех, с которыми он знаком (его компания, его отрасль и т. Д.).

Вселенная "производственных развертываний" обширна и разнообразна.

Опытный разработчик Hibernate точно знает, что DDL получит в результате данной конфигурации сопоставления. Пока вы тестируете и проверяете, что то, что вы ожидаете, заканчивается в DDL (в dev, qa, staging и т. Д.), У вас все в порядке.

Когда вы добавляете множество функций, автоматические обновления схемы могут экономить время.

Список автоматических обновлений, которые не будут обрабатываться, бесконечен, но некоторые примеры - миграция данных, добавление необнуляемых столбцов, изменение имени столбца и т. Д. И т. Д.

Также вам нужно позаботиться в кластерной среде.

Но опять же, если бы вы знали все это, вы бы не задавали этот вопрос. Хм , , Хорошо, если вы задаете этот вопрос, подождите, пока у вас не появится большой опыт работы с Hibernate и автоматическими обновлениями схемы, прежде чем подумать об использовании ее в prod.

Answer 6

Я бы проголосовал против. Hibernate, кажется, не понимает, когда типы данных для столбцов изменились. Примеры (с использованием MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Возможно, есть и другие примеры, такие как увеличение длины столбца String более чем на 255 и его преобразование в текст, средний текст и т. Д. И т. Д.

Конечно, я не думаю, что на самом деле есть способ "преобразовать типы данных" без создания нового столбца, копирования данных и удаления старого столбца. Но в ту минуту, когда ваша база данных содержит столбцы, которые не отражают текущее отображение Hibernate, вы живете очень опасно ...

Flyway - хороший вариант для решения этой проблемы:

http://flywaydb.org

Answer 7

Как я объяснил в этой статье , не рекомендуется использовать hbm2ddl.auto в производстве.

Единственный способ управлять схемой базы данных - использовать сценарии инкрементной миграции, поскольку:

• сценарии будут находиться в VCS вдоль вашей базы кода. Когда вы оформляете ветку, вы воссоздаете всю схему с нуля.
• инкрементные сценарии можно протестировать на сервере QA перед применением в производстве
• нет необходимости в ручном вмешательстве, поскольку сценарии могут запускаться Flyway , следовательно, это уменьшает вероятность человеческой ошибки, связанной с выполнением сценариев вручную.

Даже в Hibernate User Guide советуют избегать использования инструмента hbm2ddl для производственных сред.

Answer 8

Мы делаем это в проекте, работающем уже несколько месяцев, и до сих пор у нас не было проблем. Имейте в виду 2 ингредиента, необходимые для этого рецепта:

1. Создайте свою объектную модель с подходом обратной совместимости, то есть исключает объекты и атрибуты, а не удаляет / изменяет их. Это означает, что если вам нужно изменить имя объекта или атрибута, оставьте старое как есть, добавьте новое и напишите какой-нибудь скрипт миграции. Если вам нужно изменить связь между объектами, если вы уже находитесь в производстве, это означает, что ваш проект был в первую очередь неправильным, поэтому постарайтесь придумать новый способ выражения новых отношений, не затрагивая старые данные.

2. Всегда резервная копия базы данных перед развертыванием.

Мне кажется - после прочтения этого поста - что 90% людей, участвующих в этом обсуждении, приходят в ужас от мысли об использовании подобных автоматизаций в производственной среде. Некоторые бросают мяч в DBA. Потратьте немного времени, чтобы учесть, что не все производственные среды предоставляют DBA, и не так много команд разработчиков могут себе их позволить (по крайней мере, для проектов среднего размера). Так что, если мы говорим о командах, где каждый должен делать все, мяч на них.

В таком случае, почему бы просто не попытаться получить лучшее из обоих миров? Такие инструменты, как это, здесь, чтобы протянуть руку помощи, которая - с тщательным дизайном и планом - может помочь во многих ситуациях. И поверьте мне, поначалу администраторов может быть трудно убедить, но если они знают, что мяч не в их руках, им это понравится.

Лично я никогда не вернусь к написанию сценариев вручную для расширения любого типа схемы, но это только мое мнение. И после того, как я недавно начал принимать NoSQL-схемы без баз данных, я вижу, что в скором времени все эти операции на основе схем уйдут в прошлое, поэтому вам лучше начать менять свою перспективу и смотреть в будущее.

Answer 9

Я бы не стал рисковать, потому что вы можете потерять данные, которые должны были быть сохранены. hbm2ddl.auto = update - это простой способ поддерживать вашу базу данных в актуальном состоянии.

Answer 10

• В моем случае (Hibernate 3.5.2, Postgresql, Ubuntu) установка hibernate.hbm2ddl.auto=update только создала новые таблицы и создала новые столбцы в уже существующих таблицах.

• Он не удалял ни таблицы, ни столбцы, ни столбцы. Это можно назвать безопасным вариантом, но что-то вроде hibernate.hbm2ddl.auto=create_tables add_columns будет более понятным.