Які можливі значення конфігурації Hibernate hbm2ddl.auto і що вони роблять

Мені дуже хочеться дізнатися більше про оновлення, експорт та значення, які можна надати hibernate.hbm2ddl.auto
мені, я повинен знати, коли використовувати оновлення, а коли ні? А яка альтернатива?

Це зміни, які можуть статися над БД:

• нові таблиці
• нові стовпці в старих таблицях
• стовпці видалено
• тип даних стовпця змінено
• тип стовпця змінив свої атрибути
• таблиці впали
• значення стовпця змінено

У кожному конкретному випадку яке найкраще рішення?

З документації громади :

hibernate.hbm2ddl.auto Автоматично перевіряє або експортує схему DDL до бази даних, коли створюється SessionFactory. При створенні-падінні схема бази даних буде відхилена, коли SessionFactory явно закритий.

наприклад, підтвердити | оновлення | створити | створення-падіння

Отже, список можливих варіантів є,

• validate : перевірити схему, не вносить змін у базу даних.
• update : оновити схему.
• create : створює схему, знищуючи попередні дані.
• create-drop : скиньте схему, коли SessionFactory закривається явно, як правило, коли програма зупиняється.
• немає : нічого не робить зі схемою, не вносить змін у базу даних

Ці параметри, здається, призначені для інструментів розробників, а не для полегшення будь-яких баз даних про рівень виробництва, можливо, ви хочете переглянути наступне питання; Hibernate: hbm2ddl.auto = оновлення у виробництві?

Існує також незадокументоване значення "none", щоб повністю його відключити.

Викликається властивість конфігурації hibernate.hbm2ddl.auto

У нашому середовищі розробки ми налаштовуємося hibernate.hbm2ddl.auto=create-dropвипускати та створювати чисту базу даних кожного разу при розгортанні, щоб наша база даних знаходилась у відомому стані.

Теоретично ви можете налаштувати hibernate.hbm2ddl.auto=updateоновити свою базу даних зі змінами у вашій моделі, але я б не довіряв цьому у виробничій базі даних. Рання версія документації говорила про те, що це принаймні експериментально; Я не знаю поточного стану.

Тому для нашої виробничої бази даних не встановлюйте hibernate.hbm2ddl.auto- за замовчуванням не змінювати бази даних. Натомість ми вручну створюємо сценарій оновлення SQL DDL, який застосовує зміни від однієї версії до наступної.

Я б використовував liquidibase для оновлення вашого db. Функція оновлення схеми hibernate дійсно добре лише для розробника, тоді як вони розробляють нові функції. У виробничій ситуації з оновленням db потрібно поводитися більш ретельно.

Хоча це досить старий пост, але, як я провів деякі дослідження з цієї теми, так подумав поділитися ним.

hibernate.hbm2ddl.auto

Згідно з документацією, вона може мати чотири дійсних значення:

створити | оновлення | підтвердити | створення-падіння

Далі йде пояснення поведінки, показане цим значенням:

• create : - створити схему, дані, раніше наявні (якщо вони є) у схемі, втрачаються
• update: - оновити схему заданими значеннями.
• validate: - перевірити схему. Це не робить змін у БД.
• create-drop: - створити схему зі знищенням раніше наявних даних (якщо вони є). Він також скидає схему бази даних, коли SessionFactory закритий.

Нижче перелічено важливі моменти:

• У разі оновлення , якщо схеми немає в БД, схема створюється.
• У разі валідації , якщо схема не існує в БД, вона не створюється. Замість цього він видасть помилку: -Table not found:<table name>
• У разі створення-падіння схема не закривається після закриття сеансу. Він падає лише при закритті заводу сесії.

• У випадку, якщо я даю якесь значення цій властивості (скажімо, abc, замість вище чотирьох значень, обговорених вище), або це просто залишиться порожнім. Він показує таку поведінку:

  -Якщо в БД схеми немає: - Вона створює схему

  -Якщо схема присутня в БД: - оновіть схему.

По-перше, можливими значеннями hbm2ddlвластивості конфігурації є такі:

• none- Ніяких дій не виконується. Схема не буде генерована.
• create-only - Сгенерується база даних.
• drop - Схема бази даних буде скинута і створена згодом.
• create - Схема бази даних буде скинута і створена згодом.
• create-drop- Схема бази даних буде скинута і створена згодом. Після закриття SessionFactoryсхеми бази даних буде скинуто.
• validate - Схема бази даних буде перевірена за допомогою відображення сутності.
• update - Схема бази даних буде оновлена ​​шляхом порівняння існуючої схеми бази даних із відображенням сутності.

Я присвятив допис у блозі для найбільш поширених стратегій генерації DDL у сплячому режимі :

1. Це hibernate.hbm2ddl.auto="update"зручно, але менш гнучко, якщо ви плануєте додавати функції або виконувати деякі спеціальні сценарії.
2. Найбільш гнучкий підхід полягає у використанні пролітного шляху .

Однак, навіть якщо ви використовуєте Flyway, ви все одно можете генерувати початковий сценарій міграції, використовуючи hbm2ddl. У цій статті ви можете побачити, як можна поєднувати модель сутності JPA з моделлю таблиці jOOQ.

hibernate.hbm2ddl.auto автоматично перевіряє та експортує DDL до схеми, коли створюється sessionFactory.

За замовчуванням він не виконує жодного створення або модифікації автоматично в БД. Якщо користувач встановить одне з наведених нижче значень, то він робить схему DDL зміни автоматично.

• create - робимо створення схеми

  <entry key="hibernate.hbm2ddl.auto" value="create">

• оновлення - оновлення існуючої схеми

  <entry key="hibernate.hbm2ddl.auto" value="update">

• validate - перевірити існуючу схему

  <entry key="hibernate.hbm2ddl.auto" value="validate">

• create-drop - створити та скинути схему автоматично, коли сеанс починається та закінчується

  <entry key="hibernate.hbm2ddl.auto" value="create-drop">

Якщо ви не хочете використовувати Strings у своєму додатку та шукаєте заздалегідь визначені константи, перегляньте org.hibernate.cfg.AvailableSettingsклас, включений до JAR Hibernate, де ви знайдете константу для всіх можливих налаштувань. Наприклад, у вашому випадку:

/**
 * Auto export/update schema using hbm2ddl tool. Valid values are <tt>update</tt>,
 * <tt>create</tt>, <tt>create-drop</tt> and <tt>validate</tt>.
 */
String HBM2DDL_AUTO = "hibernate.hbm2ddl.auto";

• validate: перевіряє схему, ніяких змін у базі даних не відбувається.
• update: оновлення схеми поточним запитом виконання.
• create: створює нову схему щоразу та знищує попередні дані.
• create-drop: скидає схему, коли додаток зупинено або SessionFactory явно закрито.

Я думаю, вам слід зосередитись на

SchemaExport Class 

цей клас робить вашу конфігурацію динамічною, тому вона дозволяє вам вибирати будь-які комплекти, які вам найкраще ...

Оформити замовлення [SchemaExport]

validate: Вона перевіряє схему і не вносить жодних змін у БД.
Припустимо, ви додали новий стовпець у файл зіставлення та виконуєте операцію вставки, він викине Виняток, "у якому відсутній стовпець XYZ", оскільки існуюча схема відрізняється від об'єкта, який ви збираєтеся вставити. Якщо ви змінюєте таблицю, додаючи новий стовпець вручну, виконайте операцію "Вставка", вона обов'язково вставить усі таблиці у стовпчик разом з новим стовпцем. Це означає, що він не вносить жодних змін / зміни існуючої схеми / таблиці.

update: вона змінює існуючу таблицю в базі даних під час виконання операції. Ви можете додавати або видаляти стовпці за допомогою цього параметра hbm2ddl. Але якщо ви збираєтеся додати новий стовпець, який є "NOT NULL", він ігнорує додавання цього конкретного стовпця до БД. Оскільки таблиця повинна бути порожньою, якщо ви хочете додати стовпчик "НЕ НУЛЬ" до існуючої таблиці.

Починаючи з 5,0 , тепер ви можете знайти ці значення у виділеному Enum: org.hibernate.boot.SchemaAutoTooling(покращеному значенням NONEз 5.2).

Або ще краще, оскільки 5.1 ви також можете використовувати те, що поєднує в собі JPA 2 та "застарілі" дії зі сплячого DDL.org.hibernate.tool.schema.Action Enum

Але ви ще не можете DataSourceпрограмно налаштувати це. Було б приємніше використовувати це в поєднанні з, org.hibernate.cfg.AvailableSettings#HBM2DDL_AUTOале поточний код очікує Stringзначення (уривок, узятий з SessionFactoryBuilderImpl):

this.schemaAutoTooling = SchemaAutoTooling.interpret( (String) configurationSettings.get( AvailableSettings.HBM2DDL_AUTO ) );

… І внутрішні enumцінності обох org.hibernate.boot.SchemaAutoToolingі org.hibernate.tool.schema.Actionне піддаються публічному опроміненню.

Далі, зразок програмної DataSourceконфігурації (використовується в моїх програмах Spring Boot), які використовують гамбіт завдяки, .name().toLowerCase()але він працює лише зі значеннями без тире (не create-dropнаприклад):

@Bean(name = ENTITY_MANAGER_NAME)
public LocalContainerEntityManagerFactoryBean internalEntityManagerFactory(
        EntityManagerFactoryBuilder builder,
        @Qualifier(DATA_SOURCE_NAME) DataSource internalDataSource) {

    Map<String, Object> properties = new HashMap<>();
    properties.put(AvailableSettings.HBM2DDL_AUTO, SchemaAutoTooling.CREATE.name().toLowerCase());
    properties.put(AvailableSettings.DIALECT, H2Dialect.class.getName());

    return builder
            .dataSource(internalDataSource)
            .packages(JpaModelsScanEntry.class, Jsr310JpaConverters.class)
            .persistenceUnit(PERSISTENCE_UNIT_NAME)
            .properties(properties)
            .build();
}

Хто шукає значення за замовчуванням ...

Він написаний у вихідному коді у версії 2.0.5 Spring-boot та 1.1.0 у JpaProperties:

    /**
     * DDL mode. This is actually a shortcut for the "hibernate.hbm2ddl.auto"
     * property. Defaults to "create-drop" when using an embedded database and no
     * schema manager was detected. Otherwise, defaults to "none".
     */
    private String ddlAuto;