Defining a FROM Clause

   

Defining a FROM Clause

The SELECT and FROM clauses of a query are always required. A WHERE clause is part of most queries, but if the results don't need to be restricted based on a conditional expression, one isn't required. The FROM clause determines to which entities a query applies, so it's the part you need to understand first.

From the basics of SQL, you know that a FROM clause identifies the tables from which a query pulls its results. Carrying this concept over to the object world defines what a FROM clause does in EJB QL. It defines the classes associated with a query. To be technical, a FROM clause defines the domain of objects to which a query applies.

The simplest type of query is one that retrieves all the objects of a given type. For example, you saw a declaration equivalent to the following for the findAllAuctions finder method in Chapter 7:

 SELECT OBJECT(auction) FROM EnglishAuction AS auction 

Here, FROM EnglishAuction uses an abstract schema name to specify that the domain for the query consists of all the auction entity objects. The AS auction part of the query provides a way to reference an auction entity using what's known as an identification variable. The identification variable is given the arbitrary name auction in this case. Finally, SELECT OBJECT(auction) defines the result of the query using this variable. When all the pieces are combined, this query instructs the container to return all objects auction where auction is an EnglishAuction .

Identification Variables

The character strings that appear in a query are known as identifiers. To support the various operators that make up the query language, EJB QL defines SELECT , FROM , WHERE , DISTINCT , OBJECT , NULL , TRUE , FALSE , NOT , AND , OR , BETWEEN , LIKE , IN , AS , UNKNOWN , EMPTY , MEMBER , OF , and IS as reserved identifiers. The question mark ( ? ) is also a reserved character within EJB QL used for query parameters. Unlike Java identifiers, the EJB QL identifiers are case insensitive. This is true for the identifiers you define as well. This chapter always uses the upper-case form of the reserved identifiers, but select is the same as SELECT in EJB QL. Other than this behavior, you follow the same rules for naming identifiers in EJB QL that you do in your Java code. Your identifiers must start with a letter, an underscore , or a currency symbol. The remainder of an identifier can include any of these characters, digits, and certain types of control characters that you'll likely never use.

Caution

Even though not specifically prohibited , it's best to avoid using any other SQL reserved words as identifier names in your queries. As EJB QL capabilities expand in later releases, the list of reserved identifiers is likely to grow.


Identification variables are identifiers declared in a FROM clause using the AS or IN operator. You can name an identification variable anything other than a reserved identifier name or the value of an ejb-name , or abstract-schema-name element in the same deployment descriptor. In the preceding example, auction was declared as an identification variable using the AS operator. This type of declaration is called a range variable declaration because it ranges over the abstract schema of a particular entity bean without being constrained by any relationships to other entities. This type of declaration is always done by referencing an abstract schema name. The AS operator is optional and is assumed if you omit it. The same findAllAuctions query could be written as

 SELECT OBJECT(auction) FROM EnglishAuction auction 

A FROM clause can include multiple identification variable declarations separated by commas. The following example declares both auction and aBid as identification variables:

 SELECT OBJECT(auction) FROM EnglishAuction auction, IN(auction.bids) aBid 

Here a query is being performed that retrieves all auctions that have at least one associated bid. The identification variable auction is declared using the implicit AS operator as before. After you declare an identification variable for an entity, you can navigate to any of its CMR fields. The IN operator allows you to declare an identification variable that represents an entity that's reached by navigating a CMR field in a one-to-many or many-to-many relationship. In the example, aBid represents any bid in the collection of bids associated with a particular auction. You refer to the auction's bids using the name of the CMR field. You can't classify aBid as a range variable because it doesn't refer to all the AuctionBid objects in the system. A declaration that uses IN is referred to as a collection member declaration instead. Within the query, auction.bids represents a collection of objects of the abstract schema type AuctionBid . Identification variables are evaluated left to right, so it's legal for auction to be referenced in the declaration of aBid but not the other way around. The IN operator uses an implicit AS if you omit it, so the query also could be written as

 SELECT OBJECT(auction) FROM EnglishAuction AS auction, IN(auction.bids) AS aBid 

You might be confused by the intent of this query because it's not immediately clear. If you remove the part of the FROM clause that uses the IN operator, this query reverts back to the findAllAuctions declaration. By specifying that the bids CMR field should be navigated for each retrieved auction, the query effectively filters out all auctions that have an empty collection of bids. This is an important side effect to be aware of when declaring identification variables. You'll see a more intuitive version of this query when the WHERE clause is covered.

Identification variables always represent entity beans (as opposed to a CMP field or any other value). You can declare them only using AS and IN , which can appear only in the FROM clause of a query.

Path Expressions

The expression auction.bids in the preceding example is known as a path expression. A path expression consists of an identification variable and a CMR or CMP field separated by the dot navigation operator ( . ). You use path expressions to further narrow the domain of a query. The type of field that a path expression navigates to defines the type of the path expression itself. This means that the result of the navigation defines the result of a path expression. The expression auction.bids evaluates to a collection of AuctionBid objects. An expression such as this that navigates to a collection-valued CMR field is called a collection-valued path expression . This is the only type of path expression you can use with the IN operator. When you use IN , you're declaring a variable to represent an object of a particular abstract schema type in a collection that was reached by navigating a CMR field. A path expression that navigates a CMP field or a one-to-one or many-to-one CMR field is called a single-valued path expression .

If a path expression navigates to a CMR field, you can continue navigating to that entity's CMP fields or its other relationships. As an example, the following path expression navigates to the bidder who placed the winning bid for an auction:

 auction.winningBid.bidder 

Here, auction.winningBid is a single-valued expression that evaluates to a CMR field that holds an AuctionBid . Because this is a single-valued CMR field, it can be further navigated. In this case, the dot operator is applied to navigate to the Bidder that is associated with the winning bid. You can navigate to CMP fields as well. The navigation here could continue as in the following:

 auction.winningBid.bidder.emailAddressField 

This path expression gets the e-mail address of the winning bidder. Applying the dot operator to the result of auction.winningBid allows you to navigate to the bidder and produce a result of the bidder's abstract schema type. This result is then navigated to one of its CMP fields. In this example, the result of the entire expression is the CMP field (a String ) that defines the bidder's e-mail address.

Because auction.bids produces a collection-valued result, it can't be navigated. You must use the IN operator to further access the results of a collection-valued path expression.



Special Edition Using Enterprise JavaBeans 2.0
Special Edition Using Enterprise JavaBeans 2.0
ISBN: 0789725673
EAN: 2147483647
Year: 2000
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net