JPA: Entity without an ID

A problem that I’ve recently encountered myself not so long ago, I wanted to know how to query a table that essentially had no ID/primary key column. I had to do this since the table(s)/view(s) that I needed to query could be considered legacy, they perform rather poorly & generally, from a DB perspective need a lil’ TLC.

But since I’m employed as a software engineer & the data warehouse team takes care of tasks such as this, it’s not my call as to whether or not these table(s) or view(s) should be updated in anyway. Since these table(s) & view(s) are being used for MI purposes/processes, it’s not something that suitable to experiment with in a live environment to say the very least, I think it’s reasonable that we can all agree on this one. Even within a development environment, since my team have migrated to Azure, we’re trying to keep costs to a minimal, for obvious reasons, so if I don’t need to add more data to the Azure DB’s, I probably should think again.

Anyhow, back to the story, let’s just say I don’t have the necessary permissions to make any alterations to the database layer. Ultimately that just means all I can do, as a mere software engineer is alter the application layer. Which is exactly what I ended up doing, some of these views are incredibly large, the sheer number of columns alone is quite a sight to behold, regardless of the amount of data within these views.

Since we’re going down the route of using Spring Boot & a SOA/Microservice ecosystem, I wanted to take advantage of what Spring Data had to offer, I wanted to implement queries using JPA Repositories. Only, I ran into an issue when defining my entity classes, that being the fact that they had no ID field, so I tried to use the embeddable ID annotation. Only due to how poorly structured this table was, I couldn’t just stop there, I had to find a way to map the unusual column names to my properties within my embeddable class.

So I decided to utilise the attribute override annotation, I was thrilled to see that I finally had a code base where from a logical perspective it works, but how well that would work in practice is another thing. I ended up with what essentially looked like nested entities, but due to the structure of the DB, I simply had no other option. But, thankfully, since I was essentially refactoring an existing feature, I had a good start regarding documentation, since trying to make sense of the column names alone would be a nightmare.

The issue that we experienced with the existing business logic is that it would try to load an immense amount of data all at once, rather than load different blocks of data depending on the request. As an example, maybe you’d have one section of the front end that would display the insurance policy information such as price, dates, etc, another explicitly displaying any claims associated with that policy, I’m sure you get the idea. So, I decided to break it up in the front end & the back end, since the front end is being writing using Angular, that was a breeze. It was essentially consisting of a base component that was somewhat smart, then having several dumb components that would load the different blocks of data, by passing the service class a specific URL. Having done this alone, it’s increased the speed of this feature alone quite dramatically. Without further tweaks such as caching, the performance difference is rather significant.

P.S. If you’ve managed to stick around this long, take my advice when I say that you need to use lombok, it’s just epic, it’s so straightforward & it makes your code much more readable, not to mention how it simplifies implementing certain features. Whether you want to implement a private constructor on some utility class or have some builder implemented on your domain classes, you can do all of these with some simple set of annotations.