Create rules for migration to Hibernate 5.6 #206
Conversation
Signed-off-by: Jason Froehlich <[email protected]>
Signed-off-by: Jason Froehlich <[email protected]>
| or: | ||
| - builtin.filecontent: | ||
| filePattern: (hibernate\.properties|persistence\.xml|cfg\.xml|application\.properties|application\.yaml) | ||
| pattern: hibernate.bytecode.provider=javassist |
There was a problem hiding this comment.
I think this pattern would only be valid for *.properties files, right?
| - builtin.filecontent: | ||
| filePattern: (hibernate\.properties|persistence\.xml|cfg\.xml|application\.properties|application\.yaml) | ||
| pattern: hibernate.bytecode.provider=javassist | ||
| - as: hibernate_cfg |
There was a problem hiding this comment.
I think we can remove this as field, since it's now being used anywhere. The same with the one below, as: persistence_files.
| - java.referenced: | ||
| location: FIELD | ||
| pattern: java.sql.Clob | ||
| - as: config_files # Check for PostgreSQL 8.1 dialect |
There was a problem hiding this comment.
We don't need this as field. This is basically used when the outcome of a subcondition is needed in the next subcondition, providing some sort of "chaining", but here is not necessary.
| - as: config_files # Check for PostgreSQL 8.1 dialect | ||
| builtin.filecontent: | ||
| filePattern: .*\.(java|properties|xml) | ||
| pattern: org.hibernate.dialect.PostgreSQL81Dialect |
There was a problem hiding this comment.
Should we add a subcondition looking for PostgreSQL dependency too, or would it be enough with this? Not sure if this property is always used. If we don't need the dep condition, then better.
| message: | | ||
| Using `@Lob` or `java.sql.Clob` with PostgreSQL 8.1 dialect might require DDL type changes for CLOBs. | ||
|
|
||
| Consider reviewing DDL generation for CLOB columns and potential migration to 'oid' type if necessary. |
There was a problem hiding this comment.
I would add some information about this potential data loss, which looks quite worrying:
All PostgreSQL JDBC drivers unfortunately just store the oid it created for a java.sql.Clob into the text column. Although reading back the value with the CLOB API works, PostgreSQL has no knowledge of the reference to the LOB, because the oid is not known to PostgreSQL, leading to data loss when vacuumlo (the utility to clean up unused LOBs) runs. To avoid the data loss, it is required to use the oid type so that vacuumlo can see the reference.
Updating to 5.6.2 does not require any schema or application changes by default, but we highly recommend that you migrate existing text columns for LOBs to oid to prevent data loss due to the activity of vacuumlo.
These were the only 2 items found in the hibernate migration guide