Migrating away from JPA back to simple SQL

Question

After years of development with TopLink/EclipseLink in a production application with around 100 tables we have decided that enough is enough and that JPA is not worth the added complexity and uncertainty of its actual operations, and that SQL (with some wrapper like DBUtil or something like that) can do the job just right for us.

Can you suggest how one would go about migrating a pretty large JPA application to JDBC/SQL in a way that would leave JPA still running (i.e. in the webapps with GUI) but that would allow us to still start with the "downgrade" to JDBC?

We have entities and DAOs, but my real worry is the JPA entitycache (primary one) - is it possible to disable it completely so that JPA acts as a simple connection.begin(); entries... connection.commit(); in the interim, until we get rid of it for good?

Answer 1

An idea would be to introduce a repository layer. You introduce repositories and quickly implement core api with JPA, probably reusing quite a lot of existing code of data access.

The point is that in the same time you start to refactor whole application to use repositories instead of JPA directly.

Then, yet another team could work on repositories implemented with pure jdbc and test the jdbc implementation against jpa implementation - as jdbc and jpa repositories implement the same set of interfaces, conformance tests are obvious.

To summarize, following happens concurrently:

• you design your interface layer to meet the needs of actual business code
• you implement repositories with existing jpa code
• you refactor your business code to use repositories
• you implement the same repositories with jdbc and implement conformance tests

All that's all. When there is enough confidence, you just switch your repositories implementations to jdbc repositories and keep your jpa repositories for backward compatibility tests only.

Answer 2

I hope you guys have some good unit and integration test. If not, then this is where to start.

After that, in a first step you could create an abstract factory through which you provide access to all your DAOs and entities and change all access from clients to go over that factory. In this step you'll have to provide an implementation for that factory, create a concrete factory JpaAccessFactory and let its methods return DAOs and entities filled using JPA.

When you are sure nothing went bad with the first step. then proceed with the second step.

Create a factory implementation SqlAccessFactory witch fills the DAOs and entities (objects of entity classes are here actually just DAOs) using SQL. Write some unit tests witch uses both factories and make the asserts using expected provided by JpaAccessFactory and actual provided by SqlAccessFactory.

When you are done with implementing the factory method for a table and all its dependencies in SqlAccessFactory, let the client / page that uses the DAO or entity provided by this method, use the new factory for retrieving it. You could make this configurable so you wont have to change the code to change witch factory is beeing used. This also would have the benefit to easily switch back if you find out that something is not as it should be.

Factory methods witch are not yet implemented in SqlAccessFactory could just throw an Exception

throw new UnsupportedOperationException
    ("Not yet implemented, please configure your client / page to use JPA.");

I hope this gives some hints one where and how to start.