Мокко синхронное & ldquo; перед всеми & rdquo; тайм-аут

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

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

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

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

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

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

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

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