If you are working with a legacy application, there are a few considerations to keep in mind, such as reverse engineering and modernization. Let's discuss those here.
There are times that you just want to migrate your data access from another technology—such as raw JDBC, Spring JdbcTemplate, or MyBatis to Hibernate.
The JBoss team offers a very nice eclipse plugin that provides very useful functionalities, such as model viewer, mapping diagram HQL editor, and reverse engineering. Using this feature, you can extract enough information from the database (using the appropriate database dialect) to generate Hibernate mapping files, Java classes, annotations, and more. We will not discuss the steps for reverse engineering an existing database, as clear instructions are available online. For further information, visit http://tools.jboss.org/features/hibernate.html.
We would like to share a few useful hints to help you create better maps when reverse engineering:
- ID column: If your database table lacks a primary key or it enforces the primary key using a unique index, Hibernate will not be able to identify the right column designated for the primary key. In this case, add a primary key or replace the unique index with a primary key; otherwise, Hibernate will create an embedded ID that will include every column of that table.
- Composite ID: If a table has two composite keys comprised of two or more columns, Hibernate will correctly create an embeddable to represent the ID. So, make sure that the appropriate columns are designated as primary keys.
- Associations: When a table column refers to another table column, ensure that a foreign key constraint exists so that Hibernate can create the appropriate associations for you. Also, the fetch types for the associations are always set to
LAZY.
The eclipse plugin offers very handy features. For example, you can customize the reverse engineering file to map data types, columns, and table filters, using the provided user interface, or you can edit the XML directly.
Often, we face the challenge of modernizing a legacy application. But, we almost never we have the luxury of suddenly shutting down the current legacy application and switching to the modernized version. For that reason, when you push the modernized version of your application to production, it has to coexist with the legacy application until the legacy version is slowly retired.
There are typically two scenarios in cases like this:
In cases when both the application and the database are being modernized, besides having to migrate the data to the modernized database, you'll also have to account for the synchronization effort between the legacy and the modernized database. Some developers use the two-way Extract-Transform-Load (ETL) to keep the databases in sync. You can use Hibernate to push data generated in the modernized application to both databases, using events or interceptors; we discussed this in Chapter 6, Events, Interceptors, and Envers. (Ensure that you use a global transaction for this, so that, if one transaction fails, both transactions are rolled back.) However, you still have to use tools and techniques such as ETL to pull data from legacy databases. If your legacy database tables have an update column, you can write your own ETL utility and create a pull job, and use the update time as the entity version. It's highly recommended that you use a staging table to minimize the impact on application tables. Also, if you create a pull job, depending on the problem domain, you should reduce the frequency of the pulls to minimize the chances of database contention.
Another approach is to first migrate the application and then the database. In that case, you will deal with the second problem—two applications and one database. And for that, you will need to carefully examine transactions and lock strategies in both applications. In scenarios like this, you should minimize the use of cached data. You can still cache data that is never or rarely modified.