JPA 2.0 has added support for persistent maps where keys and values may be any combination of basic types, embeddables or entities.
Let's start with a use case:
The Use Case
In an internationalized application, working with plain old
Strings is not enough, sometimes you also need to know the language of a string, and given a string in English, you may need to find an equivalent string in German.
So you come up with a
LocalizedString, which is nothing but a plain old
String together with a language code, and then you build a
MultilingualString as a map of language codes to
LocalizedStrings. Since you want to reuse
LocalizedStrings in other contexts, and you don't need to address them individually, you model them as an embeddable class, not as an entity.
The special thing about this map is that the keys are part of the value. The map contents look like
'de' -> ('de', 'Hallo')
'en' -> ('en', 'Hello')
The Model
This is the resulting model:
[Update 20 July 2010: There is a slight misconception in my model as pointed out by Mike Keith in his first comment on this post. Editing the post in-place would turn the comments meaningless, so I think I'd better leave the original text unchanged and insert a few Editor's Notes. The @MapKey annotation below should be replaced by @MapKeyColumn(name = "language", insertable = false, updatable = false) to make the model JPA 2.0 compliant.]
@Embeddable
public class LocalizedString {
private String language;
private String text;
public LocalizedString() {}
public LocalizedString(String language, String text) {
this.language = language;
this.text = text;
}
// autogenerated getters and setters, hashCode(), equals()
}
@Entity
@Table(schema = "jpa", name = "multilingual_string")
public class MultilingualString {
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
@Column(name = "string_id")
private long id;
@ElementCollection(fetch=FetchType.EAGER)
@MapKey(name = "language")
@CollectionTable(schema = "jpa", name = "multilingual_string_map",
joinColumns = @JoinColumn(name = "string_id"))
private Map<String, LocalizedString> map = new HashMap<String, LocalizedString>();
public MultilingualString() {}
public MultilingualString(String lang, String text) {
addText(lang, text);
}
public void addText(String lang, String text) {
map.put(lang, new LocalizedString(lang, text));
}
public String getText(String lang) {
if (map.containsKey(lang)) {
return map.get(lang).getText();
}
return null;
}
// autogenerated getters and setters, hashCode(), equals()
}
The SQL statements for creating the corresponding tables:
CREATE TABLE jpa.multilingual_string
(
string_id bigint NOT NULL,
CONSTRAINT multilingual_string_pkey PRIMARY KEY (string_id)
)
CREATE TABLE jpa.multilingual_string_map
(
string_id bigint,
language character varying(255) NOT NULL,
text character varying(255)
)
The Specification
The most important and most difficult annotation in this example is
@MapKey. According to JSR-317, section 2.1.7 Map Keys:
If the map key type is a basic type, the MapKeyColumn annotation can be used to specify the column mapping for the map key. [...]
The MapKey annotation is used to specify the special case where the map key is itself the primary key or a persistent field or property of the entity that is the value of the map.
Unfortunately, in our case it is not quite clear whether we should use
@MapKey or
@MapKeyColumn to define the table column for our map key. Our map key is a basic type and our map value is not an entity, so this seems to imply we should use
@MapKeyColumn.
On the other hand, our key is a persistent field of the map value, and I think the whole point of the
@MapKey annotation is to indicate the fact that we simply reuse a property of the map value as the map key, so we do not need to provide an extra table column, as the given property is already mapped to a column.
The way I see it, replacing
@MapKey by
@MapKeyColumn(name = "language_key") - note the
_key suffix! - is also legal, but then we get a different table model and different semantics: The table
jpa.multilingual_string_map would have a fourth column
language_key, this
language_key would not necessarily have to be equal to the language of the map value.
Another open question: Is it legal to write
@MapKeyColumn(name = "language")? If so, this should indicate that the language column is to be used as the map key, so this would be equivalent to the
@MapKey annotation. On the other hand, you might say that this annotation indicates that the application is free to use map keys that are independent of the map values, so this contract would be violated if the column name indicated by the annotation is already mapped.
The Persistence Providers
I've tried implementing this example with the current versions of Hibernate, Eclipselink, OpenJPA and DataNucleus.
I did not succeed with any of them. Only OpenJPA provided a workable solution using
@MapKeyColumn, but as I said, I'm not sure if this usage is really intended by the specification.
[Update 20 July 2010: With the corrected model, the updated verdict is: Only OpenJPA passes the test, the other three bail out for various reasons.]
Let's look at the contestants in turn:
Hibernate
Using the mapping defined above, Hibernate 3.5.3-Final complains:
org.hibernate.AnnotationException: Associated class not found: LocalizedString
Apparently Hibernate is expecting the map value to be an entity not an embeddable.
Using
@MapKeyColumn(name = "language"), the exception is
org.hibernate.MappingException: Repeated column in mapping for collection: MultilingualString.map column: language
Finally, with
@MapKeyColumn(name = "language_key"), Hibernate no longer complains about duplicate columns, but I end up with a redundant table column in my database which I was trying to avoid.
Another problem with Hibernate is different behaviour when working with XML mapping data instead of annotations (which is what I prefer for various reasons, but that's a topic for another post).
Using XML metadata for this example, Hibernate happily ignores the table names from the metadata and simply uses the default names. I filed a bug report in April 2010 (
HHH-5136), with no reaction ever since.
Eclipselink
Using Eclipselink 2.1.0, I simply get a rather cryptic exception
java.lang.NullPointerException
at org.eclipse.persistence.internal.queries.MapContainerPolicy.compareKeys(MapContainerPolicy.java:234)
With
@MapKeyColumn=(name = "language"), Eclipselink also complains about a duplicate column, and changing the name to
language_key, my test finally passes, at the expense of a redundant column, as with Hibernate.
OpenJPA
With OpenJPA 2.0.0, the message is
org.apache.openjpa.persistence.ArgumentException: Map field "MultilingualString.map" is attempting to use a map table,
but its key is mapped by another field. Use an inverse key or join table mapping.
which I can't make sense of. Switching to
@MapKeyColumn=(name = "language"), the new message is
org.apache.openjpa.persistence.ArgumentException:
"LocalizedString.text" declares a column that is not compatible with the expected type "varchar".
Its seems OpenJPA is confused by the column name
text which sounds like a column data type. After adding
@Column(name = "_text") to
LocalizedString.text, my test case works and my database table only has three columns.
DataNucleus
DataNucleus 2.1.1 complains
javax.persistence.PersistenceException: Persistent class "LocalizedString" has no table in the database,
but the operation requires it. Please check the specification of the MetaData for this class.
I'm getting the same message with all three variants of the annotation, so it appears that DataNucleus simply cannot handle embeddable map value and expects them to be entities.
Conclusion
Mapping maps with JPA is much harder than you would think, both for the user and for the implementor. Hibernate, Eclipselink and OpenJPA have all passed the JPA TCK. DataNucleus would have liked to do so, but they have not yet been granted access to the TCK.
All four implementors failed this simple map example to various degrees, which implies that there are features in the JPA 2.0 specification which are not sufficiently covered by the TCK.
An Open Source TCK for JPA would help in detecting and eliminating such gaps instead of leaving that to the initiative of individuals.
