hibernate: значение hbm2ddl в рабочей среде [дубликат]

• Обычно корпоративные приложения в крупных организациях работают со сниженными привилегиями.
• Имя пользователя базы данных может не иметь привилегии DDL для добавления столбцов, которые требуется hbm2ddl.auto=update.

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

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

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

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

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

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

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

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

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

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

Я бы не голосовал. 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

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

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

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

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

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

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

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

Это небезопасно, не рекомендуется, но это возможно.

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

Ну, основные проблемы и риски найденные в этом решении:

• Развертывание в неправильной базе данных. Если вы допустили ошибку для запуска сервера приложений со старой версией приложения (EAR / WAR / etc) в неправильной базе данных ... У вас будет много новых столбцов, таблиц, внешних ключей и ошибок. Та же проблема может возникнуть с простой ошибкой в ​​файле данных, (скопируйте / вставьте файл и забудьте изменить базу данных). В резюме ситуация может быть катастрофой в вашей базе данных.
• Сервер приложений занимает слишком много времени, чтобы начать. Это происходит из-за того, что Hibernate пытается найти все созданные таблицы / столбцы / etc каждый раз, когда вы запускаете приложение. Он делает это, чтобы знать, что (таблица, столбец и т. Д.) Необходимо создать. Эта проблема будет только ухудшаться.
• Инструменты базы данных практически невозможно использовать. Чтобы создать скрипты для базы данных, вам нужно подумать о том, что будет создано автоматическим обновлением после запуска сервера приложений. Если вам нужно заполнить новый столбец (на пример) некоторыми данными, вам нужно запустить сервер приложений, дождаться, пока Hibernate создаст новый столбец и после этого запустит сценарий SQL. Инструменты, такие как Flyway, почти невозможно использовать с включенным автоматическим обновлением.
• Изменения в базе данных не централизованы. С возможностью создания Hibernate таблиц и всего остального трудно просматривать изменения в базе данных в каждой версии приложения, потому что большинство из них автоматически.
• Поощряет мусор в базе данных. Из-за простоты автоматического обновления есть вероятность, что ваша команда пренебрегает удалением старых столбцов и старых таблиц.
• Неминуемая катастрофа. Неминуемый риск возникновения какой-либо катастрофы в производстве (как некоторые люди упомянули в других ответах). Даже если приложение работает и обновляется в течение многих лет, я не думаю, что это безопасно. Я никогда не чувствовал себя в безопасности.

Итак, я не буду рекомендовать использовать автоматическое обновление на производстве.

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

• Разделенные сети. Ваша тестовая среда не может получить доступ к среде гомолога. Это помогает предотвратить развертывание, которое должно было быть в тестовой среде, изменить базу данных Homologation.
• Управлять порядком сценариев. Вам нужно организовать сценарии для запуска до развертывания (изменение структуры таблицы, таблицы / столбцов таблицы) и сценария после развертывания (заполнять информацию для новых столбцов / таблиц).

И, разные из других сообщений, я не думаю, что автообновление включало его в связи с «очень хорошо оплачиваемыми» администраторами баз данных (как упоминалось в других сообщениях) ... Администраторы баз данных имеют более важные функции, чем писать инструкции SQL для создания / изменения / удалить таблицы и столбцы. Эти простые повседневные задачи могут быть сделаны и автоматизированы разработчиками и переданы только команде DBA для рассмотрения, не требуя, чтобы Hibernate и администраторы баз данных «очень хорошо оплачивали», чтобы написать их.

Я согласен с Владимиром. Администраторы в моей компании определенно не оценили бы это, если бы я даже предложил такой курс.

Кроме того, создание SQL-скрипта вместо слепого доверия к Hibernate дает вам возможность удалить поля, которые больше не используются , Hibernate этого не делает.

И я считаю, что сравнение производственной схемы с новой схемой дает вам еще более глубокое понимание того, как вы изменились в модели данных. Вы знаете, конечно, потому что вы это сделали, но теперь вы видите все изменения за один раз. Даже те, которые заставляют вас идти «Что за черт?!».

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

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

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

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

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

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

http://www.liquibase.org/

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

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

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

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

Вы должны учитывать, что эволюция схемы имеет несколько аспектов:

1. эволюция схемы базы данных при добавлении большего количества столбцов и таблиц
2. удаление старых столбцов, таблиц и отношений
3. заполнение новых столбцов по умолчанию

Инструменты гибернации важны, в частности, в случае (например, по моему опыту), у вас разные версии одного и того же приложения во многих различных типах баз данных.

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

Итак, что бы я сделал: действительно используйте возможности инструментов Hibernate для обновления схемы, но вы должны добавить вместе с ним некоторые обратные вызовы обслуживания данных и схемы, например, для заполнения значений по умолчанию, сброса более не используемых столбцов, и тому подобное. Таким образом, вы получаете преимущества (сценарии обновления базы данных, независимые от схемы, и избегаете дублирования кодирования обновлений, в реальном времени и в сценариях), но вы также охватываете все аспекты операции.

Так, например, если обновление версии состоит только в добавлении свойства varchar valued (следовательно, column), которое по умолчанию может иметь значение null, при этом автоматически будет выполнено обновление.

Предполагается, что приложение, когда оно обновлено, может обновить свою схему (это может быть сделано), что также означает, что он должен иметь права пользователя сделать это на схеме. Если политика клиента предотвращает это (вероятно, случай с ящерицей Lizard), вам придется предоставить сценарии, специфичные для базы данных.

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

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

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

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

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