What Is the EJB Query Language?

The EJB Query Language (EJB QL) is a SQL-like language defined for use with EJB 2.0 CMP. EJB QL is what you use to define the queries that determine the results of finder and select methods. Select methods didn't exist prior to EJB 2.0, and every vendor had a different syntax for defining finder methods . EJB QL offers portability across vendors using a syntax based on a subset of SQL92. Because it's based on SQL, the language is easy to learn if you're comfortable with relational databases. More importantly, once you learn it, you won't have to learn a new query language if you later switch CMP implementations. The introduction of the EJB QL is central to the goal of portability across CMP implementations touted by EJB 2.0, and it's a major factor in distinguishing EJB 2.0 from 1.1.

When your entity beans are mapped to a relational database, the queries you define using EJB QL are compiled to SQL. You saw examples of this in the preceding chapter. The two finder methods and the select method needed for the auction entity bean were declared in the ejb-jar.xml file using EJB QL. When the container tools were executed to create the concrete bean class, SQL statements were generated to implement each query. Compiling an EJB QL statement to the target language of the data store moves the responsibility of query execution to the native facilities of the database. This is a more portable approach than requiring the container to execute queries based on its representation of entity objects. When you define a query in EJB QL, it's independent of how your entities are eventually mapped to the data store used by an application. Whenever a set of related entities needs to be deployed in a new environment, you execute the corresponding vendor tools to map your logical model to the persistent store and create the concrete classes. Tying the implementation of a query to the selected deployment environment allows for performance optimization that wouldn't be possible otherwise . Even though you define your queries generically, the container provider's tools generate code to execute them that uses knowledge of the data store it's accessing.

Note

Although EJB QL queries used with a relational database are implemented using SQL statements, the results you see in your applications are always returned as objects and not data rows. As you'll see throughout this chapter, these objects typically are entity objects, but they also can include any type associated with a CMP field.

EJB QL is used only with finder and select methods, which you've been introduced to in earlier chapters. Given that you have an initial understanding of how those methods are used, what you need to know about EJB QL revolves around learning the syntax for a query. You should be somewhat comfortable with finder methods at this point because you've seen examples of them using both BMP and CMP. They're also fairly straightforward in purpose because all they ever do is return component interface references for the entity bean class for which they're defined. Select methods aren't quite as straightforward. First of all, they apply only to CMP and they're limited to internal use by the bean class that defines them. As far as learning EJB QL goes, an even bigger difference is that they can return references to other entity bean types or values other than component interface references altogether. By learning the EJB QL syntax for select methods, you should gain a better understanding of how you might use them in your applications.

Whether it's used for a finder or a select method, an EJB QL query is defined by a string in a deployment descriptor that includes a SELECT , a FROM , and an optional WHERE clause. You'll learn how to define each of these clauses as the chapter progresses.

Dependence on the Abstract Persistence Schema

The first concept to get accustomed to is that EJB QL refers to an entity bean using the name defined in its abstract persistence schema. In fact, the only reason you assign a name to an abstract persistence schema is to provide a way to reference the corresponding entity bean in a query. The only names you can use when you declare an EJB QL query are the abstract schema names of the beans in the same deployment descriptor and the names of their CMP and CMR fields. You never reference the names of any implementation classes or interfaces when you're using EJB QL, although it's accepted practice for the abstract schema name of an entity bean to be the same as the name of its local interface.

If you think back to the contents of the ejb-jar deployment descriptor related to CMP covered in Chapter 7, "Container-Managed Persistence," you'll remember that the abstract persistence schema for a bean defines only the schema name and the names of the bean's CMP fields. Table and column names don't enter the picture until the vendor-specific files generated by the deployer come into play. Any relationships between beans in an ejb-jar deployment descriptor are defined by identifying the CMR fields involved and the multiplicity of each role. Again, foreign and primary keys aren't identified at this point. Because the EJB QL queries for a bean also are declared in the ejb-jar.xml file, the schema names and the CMP and CMR field names are all you have available when defining a query. The result is that your queries never include references to the particular data store used when deploying the application. You can implement and deliver your bean classes and their query declarations without having any knowledge of the physical mapping used to persist them.