The EJB 2.0 Query Language
The new EJB 2.0 query language (EJB QL) allows the developer to navigate entity objects and their
relationships for EJB finder methods – and also to select entities and field values for use in the entity's
implementation. So not only does the EJB 2.0 specification provide for a solution to the problem of
portably defining the behavior of CMP finder methods, it also provides us with an exciting new
querying capability.
Finder methods are familiar from their role in the EJB 1.1 specification. They are defined in the home
interface of the entity bean and available for use by the client. Every entity bean must have a
findByPrimaryKey() method that takes an instance of its primary key as a parameter and returns a
single instance of that entity type (or throws a javax.ejb.FinderException to indicate that the
object was not found). Since the behavior of this mandatory method is already well defined, the EJB
component developer does not need to associate it with a query using the new query language.
Additional finder methods may be defined in the local home or remote home interfaces. Each one of
these finder methods must be associated with an EJB QL query in the deployment descriptor.
Additionally, the component developer may also define ejbSelect() methods in the entity's
implementation class. These ejbSelect() methods are not exposed to the client, and are used only as
part of the implementation. However, they provide the component developer with access to the
powerful facilities of the query language to access entities and their container-managed fields.
Similarity to SQL-92
The EJB QL was based on a subset of SQL-92 and enhanced by path expressions that allow the
component developer to navigate over the relationships defined between entity objects. Rather than
working with relational database tables, EJB QL works with the definitions of entities (known as their
schemas) and their relationships in the deployment descriptor. The schema of an entity bean is
referenced in EJB QL by its abstract-schema-name, defined in the deployment descriptor using the
element <abstract-schema-name>.
Apart from path expressions and schemas, EJB QL syntax maps fairly directly to SQL-92 syntax. This
makes it easy to learn for the component developer, and also makes it possible to compile the EJB QL
down to native SQL-92 code at deployment time (at which time the relational database schema is
known). Like SQL, EJB QL has a FROM clause, a SELECT clause, and a WHERE clause.
FROM Clause
The FROM clause is similar to the SQL from clause in that it specifies the participants in a Cartesian join
(this is explained in the next chapter). Rather than tables, the EJB QL FROM clause uses one of two
things: the schema of an entity bean in the deployment descriptor or a path expression. A path
expression specifies a navigation route from a previously referenced schema to a new schema, through a
relationship that has also been declared in the deployment descriptor.
Here is an example of a simple FROM clause. This includes an entity schema (an order bean, with a
schema name of OrderBean), and a path expression from that entity to a related entity schema
(through the OrderHasLineItems relationship). This query, which would be placed in the deployment
descriptor, returns all orders with any line items. The details will be explained in the section on EJB QL
in Chapter 6:
SELECT OBJECT(o) FROM OrderBean AS o, IN(o.lineItems) AS li
SELECT Clause
Just as in SQL, the SELECT clause in EJB QL determines what elements to return from the Cartesian
join specified in the FROM clause and qualified in the WHERE clause.
Here is a simple example of a query for an ejbSelect() method that returns a collection of entity
interfaces for line item entity components that are associated with any order:
SELECT OBJECT(li) FROM OrderBean o, IN(o.lineItems) li
WHERE Clause
Just as in SQL, the WHERE clause is responsible for qualifying the results of the Cartesian join specified
in the FROM clause. You can use many of the operators and Boolean expressions with which you are
familiar from SQL, such as =, >=, >, <=, <, <>, BETWEEN, NOT BETWEEN, LIKE, NOT LIKE, IN, NOT IN,
+, -, *, /, IS NULL, IS NOT NULL, AND, OR, (, and ).
There are also extensions specifically defined for use in the context of EJBs: you can determine whether
a multi-valued path expression has any elements by using the IS EMPTY expression, and you can
determine whether a single valued path expression is a member of a multi-valued path expression by
using the MEMBER OF expression.
You can reference the parameters to the finder or ejbSelect() method in the WHERE clause, by using a
simple syntax of a question mark plus the one-based index of the parameter, as in ?1 for the first parameter.
Here is a simple example of a query for a finder method on a remote home interface that returns a
collection of orders, where the orders have line items for the product passed in as a parameter. (If this
were a local home interface, it could not throw a java.rmi.RemoteException.) The finder method
is defined as follows:
public java.util.Collection findOrdersForProduct(String product)
throws javax.ejb.FinderException, java.rmi.RemoteException;
Here is the query statement in the deployment descriptor:
SELECT OBJECT(o) FROM OrderBean o, IN(o.lineItems) li WHERE li.product = ?1
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
