This post originated from an RSS feed registered with Java Buzz
by gregor riegler.
Original Post: I18n of JPA Entities
Feed Title: Be a better Developer
Feed URL: http://www.beabetterdeveloper.com/feeds/posts/default
Feed Description: This Blog Provides Information and Guides for "Clean Programming" and "Best Practices" in Software Development with a focus on Java
Sadly the support for i18n for Entities in JPA is actually very poor to non-existent. There's just basically no out of the box solution provided by Hibernate & Co, although i18n is a feature that could be considered mandatory for a powerful ORM Framework. If you take a look at PHP for example Doctrine supports i18n very well. So besides some really unpopular i18n extensions on forums/github you are basically on your own.
So how do you do it?
There isn't really a general solution to achieve i18n. There are many different ways and you have to choose which is actually best for you. If you do have a relatively small amount of data and ordering by translations is not necessary you can store "keys" in your tables that are being translated by Spring i18n for example. Spring i18n could store the translations in separate property files. Since you wont have to worry about performance, this is a very easy way to achieve i18n.
But lets say you have lots of data, and you need to order it on the database side. With such requirements you are better off storing translations inside your database tables. While there are guides, and also an opensource framework on the internet that implement i18n with one centralized translation-table that holds all translations i highly recommend not to follow that idea. The problem with this solution is, that you will have to add one more join for every field that has to be translated, whereas multiple joins for a single table with lots of data can easily become a performanceissue. Its better to follow the approach to create a separate translation-table for every entity. This means that you would have one entity containing simple data, and another one containing only the fields that require translation. Like so:
This schema is pretty normalized and you only have a single join on fetching an entity, while you can still order appropriate.
You could then fetch a book with its translations with:
select b from Book b joinfetch b.translations bt where bt.locale ='de';
If you cannot accept your ServiceLayer to deliver two entities for every Book only because of translations, i suggest you to implement some DTO like this BookTO which holds all values.
1 2 3 4 5 6 7 8 9 10 11 12 13
publicclassBookTO{
privateint isbn;
private String author;
private Date releaseDate;
private String title;
private String description;
}
You'd just need to map the values of Book and BookTranslation to BookTO within your ServiceLayer and also return BookTO instead of Book in your ServiceLayer.
This solution might not always be the most appropriate, but it definitely comes in handy sometimes.
Previous Topic
