New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify JPA DDL properties and auto-configuration #40177
Comments
|
…bernate.hbm2ddl.auto` is not set Fix spring-projectsGH-40177
I think the current behavior should be improved, I've created #40185 |
…bernate.hbm2ddl.auto` is not set Fix spring-projectsGH-40177
After further investigation, I realize the behavior is correct but the document is wrong. |
@nateha1984 I think it's a bug of Spring Boot 2, and Spring Boot 3 fixed it. |
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,
https://docs.spring.io/spring-boot/docs/current/reference/html/howto.html#howto.data-initialization Debugging showed that the strategy was set to |
Hibernate will only add new columns if the strategy is |
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 |
Sorry, Hibernate will alter column datatype since 6.2.0, see https://hibernate.atlassian.net/issues/HHH-15870. |
Regardless, this is potentially destructive functionality that has essentially been defaulted to off for at least 10 years and across two major versions before suddenly changing without warning. It has always defaulted to no action on non-embedded databases, and matched your documentation, since at least 1.0.0.RELEASE: https://docs.spring.io/spring-boot/docs/1.0.0.RELEASE/reference/html/howto-database-initialization.html#howto-initialize-a-database-using-hibernate Having this functionality change to be defaulted to on, without warning, intentional or not, leaves users open to the possibility of all sorts of unintended consequences. If you want to change the functionality on this, that's fine, but there should be ample warning for such a change and time for users to adjust their settings and prevent any potential issues. Calling this a documentation defect is at best disingenuous. Please reconsider this "fix" and revert the behavior back to previous functionality. |
@nateha1984 please be aware that @quaff isn't a member of the core Spring Boot team. They're an active member of the community and regular contributor that's trying to help you. Describing their help as "at best disingenuous" is unwelcome. By all means disagree with someone's opinion, but please do not bring their intentions and sincerity into question when you do so. Someone on the core team will look at this in detail when we have time. In the meantime, thank you for your patience and thank you, @quaff, for your input thus far. |
@quaff I apologize, this has been a frustrating issue for us to deal with us but I should have chosen my words more carefully. I appreciate you quickly taking up the issue to look into |
I've spent some time in the debugger where I have learned the following: With Spring Boot 2.7.8, an
The persistence unit is an instance of org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider$1. After merging the properties with those of the persistence unit, the same nine properties are present:
On the other hand, if we update
If we recreate the database (
|
My findings above show that this isn't accurate. Updates are performed as long as Hibernate supports them. It will create tables and add columns but it won't alter existing columns unless you're using Hibernate 6.2 and later. The 2.7.x docs contain the following statement about the behaviour or
My findings above show that this isn't accurate. The supplied sample sets As far as I can tell, Spring Boot's behavior hasn't changed here. The documentation is inaccurate, but that inaccuracy exists in 2.7.x and 3.x. This inaccuracy combined with a new feature in Hibernate 6.2 means that upgrading to Spring Boot 3.1.x or later can result in schema updates that would not have happened previously. The release notes for Spring Boot 3.1 contain a small section about Hibernate 6.2:
Searching the linked migration guide for Some possible actions to take:
Beyond these three steps, I don't think there's anything that we could or should do here. As far as I can tell, the behaviour of Spring Boot itself has remained consistent in terms of the configuration that's passed into Hibernate. The change that we have seen has come from a new feature in Hibernate 6.2 that's enabled by default and cannot be disabled with a configuration setting. @nateha1984 something I have learned while stepping through this is that you could disable Hibernate 6.2's new feature using a custom dialect sub-class. If you extend |
Ok, thanks for the info @wilkinsona, I guess there's nothing to be done. Very disappointed that this wasn't called out by Hibernate and it's not something Spring can easily disable given how destructive this can be. Apologies again to @quaff for my rash comments prior |
Looking at this some more, it's not as simple as a documentation fix. We also have a problem with the handling of Lines 88 to 93 in 6e37567
This is done before We're paying a heavy price for having three different ways of configuring the same thing. We used to set it to |
We've opened #40503 for some documentation improvements. We're going to hold off on any behavior changes until 3.4. We'll use this issue for those. |
In Spring Boot 2, having the
spring.jpa.generate-ddl
property set totrue
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
isnone
https://github.com/nateha1984/ubiquitous-spork
The text was updated successfully, but these errors were encountered: