Advanced Container-Managed Persistence, Page 2
The ability to find an entity is a key requirement of all entity beans. The implementation of finder methods, within EJB specification 1.1, required us to quickly move to bean managed persistence rather than use the simpler container managed persistence beans. Using EJB QL in conjunction with finder methods within a container managed persistent bean, you can meet most requirements for finding an individual or collection of entities.
We'll continue to look at our Employee entity and add a more complex finder other than findByPrimaryKey(). The requirement we need to implement is the capability to find employees based on a salary range. The following steps are required to build this finder method implementation:
Add the finder properties required to accomplish the given task.
Set the following properties (see Figure 1):
Finder editor within the EJB Designer.
Method name: findBySalaryRange
Return type: java.util.Collection
Input parameters: int low, int high
Home interface: local home
Query: SELECT OBJECT(e) FROM Employee e WHERE e.Salary BETWEEN ?1 AND ?2
Save and compile your project.
The deployment descriptor now contains the information for this finder method (see Listing 1). When the bean is deployed to the container, it translates the information contained within the deployment descriptor EJB QL to standard SQL for JDatastore.
Listing 1 Portion of the Deployment Descriptor for Defining a Finder Method with EJB QL
<query> <query-method> <method-name>findBySalaryRange</method-name> <method-params> <method-param>int</method-param> <method-param>int</method-param> </method-params> </query-method> <ejb-ql>SELECT OBJECT(e) FROM Employee e WHERE e.Salary BETWEEN ?1 AND ?2</ejb-ql> </query>
As stated earlier the introduction of relationships in EJB 2.0 specifications makes a huge difference. These relationship mappings allow for not only providing the mechanics for managing relationships, but also the capability to model and implement complex business relationships with unidirectional and bidirectional traversal.
Each entity bean typically is not isolated in itself; it relates to other entities within our system. For example, the Employee entity we have been working with relates to many other entities within our system such as the salary history. To demonstrate relationships, we will start with one-to-many and move to more complex relationships, such as many-to-many.
We can use a simple example for a one-to-many relationship. Using the sample database provided with JBuilder, each employee has a lengthy salary history that we want to make available through the instance (see Figure 2).
Model of employee to salary history.
The process for creating this one-to-many relationship within JBuilder is accomplished by using the EJB Designer. The relationship ultimately is exposed via a local interface defined on the Employee entity bean. Ultimately, you would access this local interface by way of a session façade bean, but to make the example simple, we will use the remote interface with a test client.
Expand the EmployeeData source and verify that the SALARY_HISTORY table is contained within the source's definition.
Right-click on the SALARY_HISTORY table and select Create Entity Bean. The bean then appears in the EJB Designer. Make sure that the version property is set to EJB 2.0 compliant.
Creating an EJB relationship is accomplished by right-clicking on the parent entity. In this class, right-click on our Employee entity and select Add, Relationship. An arrow used to graphically represent our relationship appears within the EJB Designer.
Drag the end of the relationship arrow onto the SalaryHistory entity.
Select the newly created method that contains the relationship. The name assigned by JBuilder's EJB Designer is salaryHistory.
The Relationship Property editor appears to allow you to change the behavior of the relationship (see Figure 3).
For the relationship properties, Multiplicity should be set to one-to-many, and Navigability should be set to unidirectional. The Navigability is set to unidirectional because it does not make sense to access Employee entity information through the SalaryHistory entity.
Click on the Edit Table Reference button to open the Table Reference editor (see Figure 4). We will use this editor to provide the link/keys between the two entities.
Adding a relationship is important because it indicates all the important keys that define the relationship between parent and child entities. Double-click on the empNo in the Employee entity and drag it onto the empNo of the SalaryHistory entity. Click OK.
You should have a new attribute that contains the relationship between the Employee and the employee's salary history. Using the property editor, shown in Figure 3, make sure that the return type of the salaryHistory method within the Employee entity is java.util.Collection.
Relationship Property editor for the Employee to SalaryHistory relationship.
Table Reference editor for the Employee to SalaryHistory relationship.
Page 2 of 3