Wednesday, August 11, 2010

EclipseLink Filters How-To

I have been assisting customers with their comparison of JPA/Object-relational frameworks as well as assisting them with migrating to EclipseLink JPA. One issue I ran into recently involves migrating users of Hibernate who use Filters over to EclipseLink. A filter is basically an additional set of criteria with session specific arguments that are applied to all queries of a given entity type.

EclipseLink has long supported additional criteria being configured on a descriptor (mapping for an entity type). In this blog I just wanted to post some simple example code that illustrates how additional criteria can be applied to a an entity type with parameters that are then specified in the creation of the EntityManager where the criteria is to be applied.

Using either an annotation on the entity class as:
public class Employee
Alternatively this customizer can be configured in persistence unit properties as well as in the eclipselink-orm.xml mapping file.

This allows for a provided customer to be called and the descriptor for the entity type, Employee in this case, to be customized. Here we'll add the additional criteria (filter) that will later be used.
public static class AddEmployeeGenderCriteria implements DescriptorCustomizer {

public void customize(ClassDescriptor descriptor) throws Exception {
ExpressionBuilder eb = new
Expression genderExp = eb.get("gender").equal(new

Note: The SessionPropertyValue class is an extension and is only required if the criteria has a parameter value that will be supplied dynamically per EntityManager.

Now with the descriptor has been customized with the additional criteria for all Employee queries we simply need to provide the argument value when creating the EntityManager.
properties.put("gender", "M");
EntityManager em = emf.createEntityManager(properties);
This will cause all queries such as:
em.createQuery("SELECT e FROM Employee e WHERE e.firstName LIKE 'J%'", Employee.class).getResultList();
To have the addtitional criteria added and the SQL generated appears as:
bind => [J%, M]
The only additional requirement is that the entity types with the EntityManager specific 'filters' be only cached in the EntityManager (isolated/txn cache) instead of the default shared cache to ensure that filtered collections from one context are not incorrectly presented in another where different parameter values are used.

The use of these types of filters is not all that common in my experience so improving the configuration has not been a priority. If you use these filters and would like to have the usage of them in EclipseLink improved we are eager to get your feedback.

Sunday, June 6, 2010

Off to Epicenter in Dublin

I am once again off to Dublin this week to speak at the Epicenter 2010 Conference again. Although I do enjoy a good Guiness I am also looking forward to the conference and the topics I am covering this week as well as the hours of travel to catch up on some pre-release tasks. We are just wrapping up our 2.1 release of EclipseLink as part of the Eclipse Helios release train and there are many new features I am excited about so travelling this week will give me a chance to complete some examples for the release and blog about the features all EclipseLink users will want to learn about.

I am speaking this week on performance and scalability. Even after 13 years of helping customers use TopLink and now EclipseLink I still find diagnosing, solving, and innovating in these areas some of the most interesting work I take part in. Helping customers learn what they need to know about their models and application use cases and translating them into their object-relational mappings, schema, and usage of their persistence layer is challenging and often poorly understand by Java developers.

The persistence layer enables performance and scalability but there are many simple decisions developers can make while configuring and coding to their persistence layer which are made early in projects and have big effects late in projects when trying to reach their performance and scalability goals. Understanding what these decisions are and what the trade-offs are is so important and hopefully I'll help some of our Irish community avoid common pitfalls.

After working with a couple clients this week dealing with tough performance goals and very complex models I have some great examples I'll be adding to my cook book of slides on my way over the Atlantic.

Hope to see you in Dublin...

Monday, February 1, 2010

EclipseLink on LinkedIn

I was back in the field last week helping a customer with their migration to EclipseLink from a 3rd party developed solution using TopLink Essentials. Generally these migrations are very straight forward but in this case we bumped into a few unique wrinkles caused by the original solution being developed on a very early version of our JPA 1.0 solution and the consultants building it introducing a partial JPA container that changed the default behaviour.

Ultimately we got the issues resolved in relatively short order and enjoyed a great meal with some of the consultants on the project in Halifax. I truly enjoy any chance I get to down into an application and help developers solve their persistence challenges.

During my visit I made some notes on a couple of take-aways.

1. Update the EclipseLink wiki's best practices to include a couple of additional scenarios around long-running transactions.

2. Help connect the existing community of Java professionals using EclipseLink.

I have already started on the first and will post some highlights here when the work is completed. To address the second action item I created the EclipseLink Group on LinkedIn.

The goal of this group is to allow any and all Java professionals who use LinkedIn to connect and share ideas, job opportunities, news, and upcoming events. If this sounds interesting to you please join the group and share your ideas.