This involves an EJB project that was running happily under JBoss 6.0.0. I’m trying to port it to WildFly 12.0.0.
The crux of the problem seems to be a difference in how hibernate auto create is generating schemas for JPA Entity Beans.
The app involves entity beans with instance fields that use collection fields like ArrayLists and arrays. The app is an EJB 2.1 app which does not use annotations, but uses an orm.xml which contains only information about the “id” fields for the entity beans. The expectation is that the JPA implementation will analyze the getters/setters and generate whatever DDL it needs to do the job. Under 6.0.0 hibernate auto appeared to serialize these things into BLOBs transparently, or at least it caused no errors. Under 6.0.0 a nightly job ran a batch app to dump serialized versions of the entity beans to flat files as a backup. There was also a batch app to restore these objects to the entities.
The problem is that under 12.0.0 the auto=create is generating DDL which maps serialized objects to BINARY(255) columns, and causing failures when we try to restore the serialized versions of the backed-up beans because the serializations involve more than 255 bytes.
I haven’t had much luck finding a detailed explanation of what auto=create does as regards generating DDL. The docs simply describe what the different values for auto do, and not the internals of how they do it.
The design of this project was to remain independent of any particular AS or JPA implementation to the greatest extent possible. The sole exception for hibernate was to include the auto=create option in a specific persistence.xml that was used only when the data was being reloaded; once the reload was done, the EJB would be rebuilt with no auto-create. So, there are no annotations and no column or table definitions in the orm.xml.
Here’s the question: why is hibernate now limiting fields containing serialized objects to 255 bytes ? Here is the error produced:
Caused by: org.h2.jdbc.JdbcSQLException: Value too long for column “ACTORS BINARY(255)”: “X’aced0005737200116a6176612e7574696c2e48617368536574ba44859596b8b7340300007870770c000001003f400000000000bb74001b6e6d303532303136… (5762)”; SQL statement:
insert into DBUtDVDTitleEntityBean (actors, associated, caseNumbers, disks, genres, keywords, runLength, seasons, title, titleKey, url, id) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [22001-193]
ACTORS should correspond to a serialized HashSet of String of primary keys into another Entity Bean store of actor info.
Again, these serialized objects were extracted from the exact same Entity Beans implemented under 6.0.0 and I am trying to reload them with the same code compiled for 12.0.0.