1

I have updated recently version of:

  • Hibernate to -> 5.6.14.Final
  • spring boot to -> 2.7.7
  • java to -> 17

And remarked that changes in @Column annotation are not reflected into DB. For example, if I add a column:

@Column(name = "visible_type_test")
private VisibleType visibleTypeTest = VisibleType.VISIBLE;

And then after running the project, decide to add nullable + columnDefinition:

@Column(name = "visible_type_test", columnDefinition = "int DEFAULT 1", nullable = false)
private VisibleType visibleTypeTest = VisibleType.VISIBLE;

The changes are not reflected.

But if I drop the column and run the project again, it is successfully adds all default values (changes are reflected)

Do you know what could be the problem ? In application properties I have this configuration set:

spring.jpa.hibernate.ddl-auto=none

I tried switching to 'ddl-auto to update', but still it did not help. Tried also to remove@DynamicUpdate annotation from entity, but also did not help.

Why it was working all this time with the current settings and now it doesn't ? Was there any hibernate updates which I am not aware of ?

Edited: I am already using flyway. My problem is not about updating column name or deleting constraints. My problem is that unique constraints are not being added if I switch a column from nullable=true, to nullable=false. Also Default value is not being added to all existing values with columnDefi ition ... Default. I DID NOT NEEDED TO CREATE FLYWAY MIGRATION BEFORE IN ORDER TO DO THIS CHANGES. THEY WERE HAPPENING AUTOMATICALLY.

Found a similar post here also with no answer provided: Spring boot tables in database not updated when entity field is modified

Michael Bat
  • 101
  • 9
  • https://stackoverflow.com/questions/26881739/unable-to-get-spring-boot-to-automatically-create-database-schema – Berk Kurkcuoglu Jan 17 '23 at 23:41
  • @BerkKurkcuoglu this is not my case. Project has connection with Database, it adds the columns, constraints etc. Also I have same configurations as remarked in the solution from this post. – Michael Bat Jan 17 '23 at 23:46
  • Only stuff which I did no try, is setting the mysql dialect from 5 to 8. Will try now – Michael Bat Jan 17 '23 at 23:48
  • @BerkKurkcuoglu tried to change hibernate dialect to org.hibernate.dialect.MySQL8Dialect , still did not help. – Michael Bat Jan 17 '23 at 23:53
  • change spring.jpa.hibernate.ddl-auto=none to spring.jpa.hibernate.ddl-auto=create-drop because after creating the tables it wont update the colums so you first have to drop then create – Anon Jan 18 '23 at 01:28
  • @Anon I can not drop the tables, as I have a lot of test data inside them. Have around 160 tables, it's a big project. Isn't there any other solution ? An alternative would be to create some migrations using flyway each time I add a column definition or a nullable attribute. But that it's just a waste of time. Before updating hibernate I did not have this problem – Michael Bat Jan 18 '23 at 01:31
  • you can try adding @ DynamicUpdate to the entity and try running it if it works you can remove after i think – Anon Jan 18 '23 at 02:31
  • `@DynamicUpdate` won't help as that is for a totally different purpose. Also you shouldn't let hibernate manage your schema as it will not create the best schema use something like Flyway (and no it isn't a waste of time to write your migrations yourself!). If you really want you should mark the ddl to at least update, but that probably only will add new columns and not change existing ones. – M. Deinum Jan 18 '23 at 07:38
  • Using flayway or liquibase is not a waste of time at all, you should manage your database schema by one of those technologies from start, then you wouldn't have this problem now and you wouldn't waste time on figuring out how to update table column. Depending on hibernate to create database schema is a really bad idea. You have now two options: change table schema manually or use flyway/liquibase to change it for you and to have all changes in the schema reflected in the code with proper history – szymon_prz Jan 18 '23 at 07:44
  • @szymon_prz guys, I am already using flyway. This is not the problem I am talking about. The problem is that before, I was not needed to create migration when a column was changed from nullable=true to nullable false. Or when a default column definition is added. But now, after updating hibernate, key unique constraints+default columns are not added automatically. – Michael Bat Jan 18 '23 at 11:11
  • @M.Deinum, remarked in comment above. I am already using flyway. This is not the problem that I am facing. – Michael Bat Jan 18 '23 at 11:12
  • As stated (and don't shout or I'll delete the question!) using `spring.jpa.hibernate.ddl-auto=none` won't change a bit in your ddl as none is nothing, you need at least `update`. Also you shouldn't be letting hibernate manage your schema in the first place even the hibernate maintainers don't advice this and that you should only use it for prototyping/testing with in memory database. You need at least `spring.jpa.hibernate.ddl-auto=update` but that might not even be sufficient dependig on your full configuration. – M. Deinum Jan 18 '23 at 11:59
  • 1
    Looking at the hibernate code generating the update (at least in the 6.x branch) it only will add new columns, it won't alter existing columns. That could be a change from previous versions but that is what the status quo is. Which isn't that weird given the fact that if you make a column non-null what should hibernate do if it encounters a null value? Also what if you add/change the default including non-null? HIbernate would need to migrate the data, which it cannot as that is on the user (which is you). – M. Deinum Jan 18 '23 at 12:22
  • Yes @M.Denium, you are right. In case default value is not set and column becomes non null, previously it wasn't handling that correctly. But in case a default value+non null was added, it was handling it pretty fine with updating the data. Ok, seems that there is no any alternatives than creating migrations for such change. – Michael Bat Jan 18 '23 at 12:50
  • @M.Deinum, you can post the answer from comments, I will accept is as correct solution – Michael Bat Jan 18 '23 at 12:54

1 Answers1

2

Looking at the code that is generating the ALTER TABLE statement, it appears to only add columns that are non-existing. It doesn't seem to alter existing columns.

That being said, AFAIK, the Hibernate team never adviced to use the DDL feature to manage your production tables but only use it for prototyping and/or quick testing.

For proper management you should use something like Flyway, more so when you migrate columns to non-null and before doing the conversion need to set a default to those columns, there are even more cases I can think off that would be problematic for altering (datatype changes, length, etc.).

That all being said, with Hibernate 5.6 and later this doesn't appear to work by design.

UPDATE: Went back all the way to the Hibernate 3.2 code in Github and even in that code it will only work for additions not changes to the column.

M. Deinum
  • 115,695
  • 22
  • 220
  • 224