Simplify JPA DDL properties and auto-configuration

[nateha1984]

In Spring Boot 2, having thespring.jpa.generate-ddl property set to true did not perform any updates as long as the corresponding hibernate properties (hibernate.hbm2ddl.auto) were not explicitly set. When updating to Spring Boot 3, the same does not apply; the schema update does take place and the Hibernate sql statement is printed to the logs (show-sql=true). Here's a git repo where the issue can be demonstrated. Steps to duplicate are in the README.

Hibernate Java Docs also indicate that if no value is provided, the default for hibernate.hbm2ddl.auto is none

https://github.com/nateha1984/ubiquitous-spork

[quaff]

https://docs.spring.io/spring-boot/docs/current/reference/html/data.html#data.sql.jpa-and-spring-data.creating-and-dropping

There is also a spring.jpa.generate-ddl flag, but it is not used if Hibernate auto-configuration is active, because the ddl-auto settings are more fine-grained.

[quaff]

https://docs.spring.io/spring-boot/docs/current/reference/html/data.html#data.sql.jpa-and-spring-data.creating-and-dropping

There is also a spring.jpa.generate-ddl flag, but it is not used if Hibernate auto-configuration is active, because the ddl-auto settings are more fine-grained.

I think the current behavior should be improved, I've created #40185

[quaff]

https://docs.spring.io/spring-boot/docs/current/reference/html/data.html#data.sql.jpa-and-spring-data.creating-and-dropping

There is also a spring.jpa.generate-ddl flag, but it is not used if Hibernate auto-configuration is active, because the ddl-auto settings are more fine-grained.

I think the current behavior should be improved, I've created #40185

After further investigation, I realize the behavior is correct but the document is wrong.

[quaff]

In Spring Boot 2, having thespring.jpa.generate-ddl property set to true did not perform any updates as long as the corresponding hibernate properties (hibernate.hbm2ddl.auto) were not explicitly set.

@nateha1984 I think it's a bug of Spring Boot 2, and Spring Boot 3 fixed it.

[nateha1984]

That may be technically correct, but this "bug" has been there for years, with behavior that matched the documentation, and it can now cause unexpected data manipulation if there is a difference in the db shema and entity mappings.

For example, a client had their id field marked as an int type in the entity but their db column in Postgres was a bigint. This mapping inconsistency was there for several years, and they had left the generate-ddl set to true the whole time as well with no issues. When we upgraded to Spring Boot 3, we suddenly saw the datatype change. Granted, this flag shouldn't have set in production and the type was incorrect; however, the behavior was matching documentation so there was no reason to suspect this migration would happen. With a large table, this type migration can lock up a table for a long period of time, and bring incoming transactions to a halt.

I feel like the fix here should be made to match Spring Boot 2 behavior, not just update the documentation. In addition, there is another section it explicitly says with Hibernate, none is the default if the datasource is not embedded (Postgres is not embedded, of course):

You can set spring.jpa.hibernate.ddl-auto explicitly to one of the standard Hibernate property values which are none, validate, update, create, and create-drop. Spring Boot chooses a default value for you based on whether it thinks your database is embedded. It defaults to create-drop if no schema manager has been detected or none in all other cases.

https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.data-initialization

Debugging showed that the strategy was set to update, not create-drop as well.

[quaff]

For example, a client had their id field marked as an int type in the entity but their db column in Postgres was a bigint. This mapping inconsistency was there for several years, and they had left the generate-ddl set to true the whole time as well with no issues. When we upgraded to Spring Boot 3, we suddenly saw the datatype change.

Hibernate will only add new columns if the strategy is update, it doesn't alter and delete columns.

[nateha1984]

For example, a client had their id field marked as an int type in the entity but their db column in Postgres was a bigint. This mapping inconsistency was there for several years, and they had left the generate-ddl set to true the whole time as well with no issues. When we upgraded to Spring Boot 3, we suddenly saw the datatype change.

Hibernate will only add new columns if the strategy is update, it doesn't alter and delete columns.

I'm sorry, but that's simply not correct. Debugger shows Hibernate config setting this property to update:

Debug in org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator, line 81. Check databaseAction HashMap and configurationValues HashMap:

Logging output:

Please check the provided sample project. This happens every single time

[quaff]

Hibernate will only add new columns if the strategy is update, it doesn't alter and delete columns.

Sorry, Hibernate will alter column datatype since 6.2.0, see https://hibernate.atlassian.net/issues/HHH-15870.