CODEWITHSUNDEEP
javasqlhibernateh2
Craig Otis
Craig Otis

Reputation: 32104

Upgrade to Hibernate4 and @ElementCollection results in inability to lookup existing data

We have a model class User that had a List<String> of permissions, like so:

@LazyCollection(LazyCollectionOption.FALSE)
@CollectionOfElements
@Column()
private List<String> permissions = Collections.emptyList();

It produced a SQL table with an entry like the following:

User permissions before H4 upgrade

We recently upgraded to Hibernate 4, and as the @CollectionOfElements annotation has gone from deprecated to completely removed, we figured this was a good time to move over to @ElementCollection, like so:

@LazyCollection(LazyCollectionOption.FALSE)
@ElementCollection // << CHANGED
@Column()
private List<String> permissions = Collections.emptyList();

Upon launching, however, we were unable to log in with our administrative account. Curious, we examined the database using H2's JAR, and found the table had been altered:

User permissions after

My questions:

  1. Is there a comprehensive list of the DDL/schema changes from the old @CollectionOfElements to the new @ElementCollection?
  2. Is there a recommended practice, or additional annotation I can provide to these properties, that will ensure backwards compatibility? (Can I specify a specific name-mapping scheme or column name?)
  3. Finally, I assume all Collection types will be affected by this change - Sets, Maps, etc. I just want to ensure that we don't leave any data behind, or stone unturned, during our upgrade.

Upvotes: 4

Views: 10542

Answers (1)

JB Nizet
JB Nizet

Reputation: 692151

First question:

I don't know of any. But the JPA specification is freely available and describes what the default table and column names are.

Second question:

@ElementCollection
@CollectionTable(name = "USER_PERMISSIONS"
                 joinColumns = @JoinColumn(name = "USER_ID"))
@Column(name = "ELEMENT")
private List<String> permissions = Collections.emptyList();

I personally always specify the table and column names. It avoids this kind of surprise, allows me to always choose the names that I want, and is self-documentary. And I also prefer creating the database schema and DDL by myself. This ensures that all required indices, constraints, comments, etc. are created correctly.

Third question: Yes, the nature of the collection doesn't matter. See the answer to your second question to avoid these kinds of problems.

Upvotes: 8

Related Questions