Как свойство spring.jpa.hibernate.ddl-auto работает в Spring?

Я работал над проектом загрузочного приложения Spring и заметил, что иногда возникает ошибка тайм-аута соединения с моей базой данных на другом сервере (SQL Server). Это особенно происходит, когда я пытаюсь выполнить миграцию сценария с помощью FlyWay, но он работает после нескольких попыток.

Затем я заметил, что я не указал spring.jpa.hibernate.ddl-auto в моем файле свойств. Я провел некоторые исследования и обнаружил, что рекомендуется добавить spring.jpa.hibernate.ddl-auto= create-drop в разработке. И измените его на: spring.jpa.hibernate.ddl-auto= none в производстве.

Но я на самом деле не понимал, как это действительно работает и как hibernate генерирует схему базы данных, используя значение create-drop или none. Можете ли вы объяснить технически, как это действительно работает, и каковы рекомендации по использованию этого свойства в разработке и на рабочем сервере. Спасибо

Ответы

Ответ 1

Для записи spring.jpa.hibernate.ddl-auto является специфичным для Spring Data JPA, и это их способ указать значение, которое в конечном итоге будет передано в Hibernate под свойством, который он знает, hibernate.hbm2ddl.auto.

Значения create, create-drop, validate и update основном влияют на то, как управление инструментом схемы будет манипулировать схемой базы данных при запуске.

Например, операция update запрашивает API-интерфейс JDBC-драйвера для получения метаданных базы данных, а затем Hibernate сравнивает создаваемую им модель объекта на основе чтения ваших аннотированных классов или сопоставлений XML-HBM и будет пытаться скорректировать схему на лету.

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

Как правило, в сценариях сценариев вы, вероятно, будете использовать create-drop чтобы создать свою схему, ваш тестовый пример добавляет некоторые макетные данные, вы запускаете свои тесты, а затем во время очистки тестового объекта объекты схемы удаляются, оставляя пустая база данных.

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

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