A beta version of Hibernate 3.5 was announced last week. The release will contain initial support for a feature called fetch profiles that is really useful for retrieving different footprints of the same entity. You can see the actual JIRA ticket HHH-3414 for more details about the feature.
Why is this useful? Let’s assume you have an Person entity with 3 associations – addresses, jobs, and hobbies. Common Hibernate wisdom advises us to keep those associations with default lazy loading settings in the mappings and override them via fetch joins at runtime for each use case. This is simple enough but let’s move on. Suppose your PersonDAO has 5 queries for finding persons by first name, last name, email, age, or some combination of the above.
This is where it gets tricky. If your application fires too many queries because lazy loading is not fetching enough data up front then you’d probably consider an optimization by providing alternative finder methods that fetch the required associated entities. So you’d have findByLastName, findByLastNameWithAddresses, findByLastNameWithJobsAndHobbies, and so on. It gets pretty confusing and the full combination is 5 finders x 10 combinations (4 + 3 + 2 + 1) = 50. And this is only an example with 3 associations without considering property paths with a depth greater than 2.
What can be even more concerning in such scenarios is that in a large application a developer that runs into a lazy loading exception or realizes that some optimization is needed would probably go back and add a ‘fetch’ join potentially affecting other scenarios and bringing back more data than is needed. There is nothing in the DAO design that would make the developer consider the performance impact because things would still work.
The fetch profiles will allow a DAO to manage all this more elegantly by accepting a parameter that represents the desired fetch profile. It would also encourage the developer to consider the available profiles without running the risk of affecting the performance of other use cases adversely.