I try to migrate to Spring Boot 1.4 that uses Hibernate 5. I have some backup script of a MariaDB database that includes table creation.
Due to spring-data-jpa in Spring Boot my entities are using the following id generation strategy.
@GeneratedValue(strategy = GenerationType.AUTO)
In my application.properties
I have
spring.jpa.generate-ddl=true
spring.jpa.hibernate.use-new-id-generator-mappings=false
The Hibernate team generally don’t recommend this setting (false value).
If I let hibernate generate the table, seem some differences with the one in the backup script.
If I use false value about the generator and use the backup script and set after that to true, I get some issue about oreign key
Cannot add or update a child row: a foreign key constraint fail...
I get same result if I keep to false.
What strategy can I use to migrate to new generator of Hibernate 5 and have data of my old database (not the structure)?
Is there a way to stay more generic? not specific to Hibernate
Spring 5x is compatible with hibernate 4x unless you are using it as an implementation of JPA which might not be compatible. A suggestion would be using the latest hibernate.
Hibernate is a proven Object Relational Mapping (ORM) framework used in many older Java applications. But, it can become a barrier to upgrading — for example, when we update your application from Struts to Spring, it may be necessary to upgrade Hibernate also.
The issue you face is that in Hibernate 4 and prior, using GenerationType.AUTO
implied that if the database you're connected to supported IDENTITY
or AUTO_INCREMENT
data types, those would be preferred over using table-based sequences.
With Hibernate 5, GenerationType.AUTO
will default to using table-based sequences for databases that previously would have used IDENTITY
or AUTO_INCREMENT
. The reason for the logic change is a bit complex, but suffice to say there are better alternatives.
My suggestion would be a multi-step migration path because this is going to be tedious depending on the size and number of tables and relationships between your entities.
false
).@GeneratedValue
annotations to use GenerationType.IDENTITY
. true
).At this point, you haven't had to change anything in your database, its stayed preciously as it was from the backup. All you've done is migrated the java code so that for new entities, you can use the new identifier mappings and preserve the old way for existing entities.
From this point forward, I would suggest migrating one entity at a time.
hibernate_sequences
table.hibernate_sequences
table for that entity's named identifier.AUTO_INCREMENT
or IDENTITY
but instead most likely something like BIGINT
or INT
. Then you want to put the foreign key constraints back.At this point, that entity should begin using the sequence table's logic rather than the native AUTO_INCREMENT
or IDENTITY
functionality that AUTO
used prior to Hibernate 5.
For large, complex systems, this won't be fun.
I had to evaluate whether we adapted to the new identifier things in ORM5 for a past project and we determined the time involved to adapt a complex, existing schema wasn't worth it. We ended up doing the first 1-5 steps to remain status-quo and then allowed new entities to leverage the new stuff. The plan was for developers go back and finish the last 1-3 steps on an as-needed basis over time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With