Hibernate.hbm2ddl.auto create no longer handling serialization gt 255

Hibernate ORM
1

Background:

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.

2

JBoss 6 was using Hibernate 3.6. Wildfly 12 uses Hibernate 5.1 or 5.2.

Therefore, you need to check the migration guides.

What you describe is possible due to a change in the dialect.

Anyway, relying on hbm2ddl for schema migration is not a good idea. You should use migration scrips and a tool like Flyway.

More, I see you are posting an exception for H2. Why is that? Are you using H2 in production?

3

Hi Vlad,
Thanks for the response. I reviewed the migration guides, but didn’t find anything describing this. There was a mention of a change related to auto, but it claimed only to affect people using specific Hibernate classes; my code (outside of the auto property in persistence.xml) contains no references whatever to Hibernate classes. I rely on JBoss/WildFly to deal with Hibernate. It is possible that there’s something in the guides which addresses this, but I just don’t see it because I’m not familiar with Hibernate architecture terminology.

I don’t understand your reference to migration scripts. To be clear, the backup files to which I refer are serializations of instances of Entity EJBs extracted from the older JBoss/Hibernate using an EJB Client application. I’m attempting to restore them with another EJB Client application. The auto=create option leaves everything up to Hibernate as to what DDL it wants to use to create the underlying tables based on the Java classes themselves. There is no Hibernate metadata or direct data being migrated, just Java objects being inserted into a new fresh H2 database.

This application is not true production. It’s a private app I wrote, and one of the design objectives was to make the install:
(a) unpack a JBoss distribution
(b) deploy the EAR
© restore the Entity data using the EJB Client app

It’s JBoss’ decision to use H2, but I approve because it doesn’t require a new user to get involved with an external RDBMS and SQL; auto=create/update and JBoss/Hibernate takes care of anything SQL-related.

4

It’s been 7 years since JBoss 6 was released so a lot has changed in Hibernate in the meanwhile.

In your case, just use the columnDefinition of the @Column annotation to specify what column type you need.

This way, you can easily fix your problem.

5

Thanks, I’ll probably end up using a workaround like that, but I think I’ll file a bug report as well. At the end of the day, autocreate is generating DDL that can’t accommodate the entity bean it’s using.

Thanks again for your help.