As it was discussed in one of the previous posts JPA: Mapping Enums the right way, JPA 2.1 standardized AttributeConverters, which can, for example, be used to map Java enums in more controlled/predicted way. Let's quickly recap how it can be done.

Using attribute converter to map java enum

Let's assume we have a PhoneType enum and a simple entity that has this enum as a field.
To be able to map this enum into the integer column of database table, which would match enum's id we need to create an attribute converter similar to the next one:
Having such converter we can annotate the corresponding filed in the entity with the @Covert annotation and that's it! This look pretty easy and doesn't require a lot of code.
What if we have one more enum? For example let's add AddressType. The process would be very similar - we need to create an attribute converter class and add @Covert annotation on the corresponding filed.
But what if we have even more enums that should be mapped this way? This would mean that we need to write a converter for each enum and basically duplicate the same logic in each of them...

Handy utility for Enums

That's where an utility class comes. In Java it is not possible to build inheritance hierarchies of enums, but it is possible for enum to implement an interface. So if we have enums that we want to map by their id to a database columns we can create an interface similar to DbEnumConstant:
Now let's make sure that our enums implement this interface:
Now that our enums have something in common we can generalize the operation of finding an enum value by id. For example next utility static method can be introduced:
But it would mean that an array of enums is needed to be passed all the time to make a call (for example like this - Utils.findByID( dbData, PhoneType.values() )). This can be solved with usage of Class#enumConstants method. DbEnumConstantHelper can be introduced, and to make it even more useful a few more variations of find methods can be added to it:
Now having such helper class, it can be added to enums for simple access to its functionality:
Finally we can get back to attribute converters.

AttributeConverter using enum helper

Now that we have all of the above in place we can write an abstract generic attribute converter for our enums with implementations for AddressType and PhoneType:

We can see that all the conversion logic is placed in the abstract converter and implementations just need to pass a helper so the right find operations would be applied.

Conclusions 

We looked once more at how Java enums can be mapped in JPA using AttributeConverter and provided a way to reduce code duplication in such converters. Even though, at first, it might not look like this amount of code  is less then writing a simple converter. But it really pays of when you have quite a few enums to map in such a way. Also this enum helper, that was introduced, is useful outside the converters as well, it gives an easy access to finding enums by their properties.

All the code samples can be found on GitHub.

To be continued ...

In this post we will take a look at couple of ways how many-to-many relationships, which have additional information, can be mapped to entities using JPA. @ManyToMany annotation cannot be applied in such cases as it does not allow to map additional information from the join table.

To show these approaches let's consider such small film rental database schema:
We have three main entity tables - actor, film, and customer. Where film_to_actor as well as rental can be called join tables with additional information. Actors are playing in the films as characters, and in our case an actor can play only one character in one film. This is represented by film_to_actor table. A customer can rent films, and he/she is not limited to one rent of a movie. Hence the rental table. Notice the difference between the rental and film_to_actor tables. film_to_actor has a composite key built from two foreign keys (film_id, actor_id), whereas rental has it's own id (as well as uuid similar to other main entities). Such difference is based on the business logic that we described earlier, as a pair of actor and film is unique we don't need additional id column, as for the rentals a pair of customer and film is not unique so in this case a separate id is added. This will help us show different mapping approaches.

Using @ElementCollection and Map for mapping many-to-many relationship with additional information

First thing first - we need to create a movie! After all the work on the film is finished we need to store it in the database somehow. Mapping actors and films is easy. An example of such mapping can be next:
That was easy enough, now what about a relation between films and actors? Well as, in our case, one actor can play one role in the film and actor identity defines which role it is, a Map is just asking to be used. An actor would serve as a map key and actor's role would be a value. Let's add such map to film entity as it is a logical place to store such information and map it with @ElementCollection.
Note, as there are three values that we need to map (main_character, first_name, last_name), we need to create an Embeddable to hold them all together at the same time:
In result we would have next class diagram:

If we would like to rather have information about in which films an actor played which character, we would place a Map in actor entity, where a film would be a map key and character information would be a map value.
We shouldn't have both such maps at the same time, mapping the same table using element collection. We should only either use it in Film or in Actor, but never in both. Let's give it a try and persist a film:
There are two things that we should look closer at here. First note that we need to persist actors separately, as we cannot benefit from cascading. But in a real application you would, most likely,  have actors persisted already. Next note that we are not exposing the Map to the users. Even though it's a good container to store key-value pairs it's much better and cleaner to provide methods on Film class to work with actors logic instead. Like in our test example we added a Film#addCharacter method:
which simply delegates the operation to the map. Similarly we can add a few more methods like this depending on the application needs:
This wraps the case of using element collections for mapping many-to-many relations with additional information. Let's move to another case.

Using @ManyToOne/@OneToMany and an entity to map many-to-many relationship with additional information

There are quite a few different approaches one can take to map enums in entities. I would separate them into three groups:

1. The ones which can be used with JPA  2.0 or less
1. Usage of @Enumerated annotation to either save enum as ordinal or its name.
2. Usage of additional pairs of setter/getter.
3. Usage of @PostLoad and @PrePersist callbacks.
2. The ones which can be used with JPA  2.1
1. Usage of AttributeConverter interface and @Convert annotation.
3. Vendor specific approach
1. Implementing custom user type in Hibernate.

Classic ways to map enums

@Enumerated(EnumType.ORDINAL) - the default approach

Hacky setter/getter