Enterprise JavaBeans, Fourth Edition

Problems with EJB QL

EJB QL is a powerful new tool that promises to improve performance, flexibility, and portability of entity beans in container-managed persistence, but it has some design flaws and omissions.

The OBJECT( ) Operator

The use of the OBJECT( ) operator is cumbersome and provides little or no value to the bean developer. It’s trivial for EJB vendors to determine when an abstract schema type is the return value, so the OBJECT( ) operator provides little real value during query translation. In addition, the OBJECT( ) operator is applied haphazardly. It’s required when the return type is an abstract schema identifier, but not when a path expression of the SELECT clause ends in a CMR field. Both return an EJB object reference, so the use of OBJECT( ) in one scenario and not the other is illogical and confusing.

When questioned about this, Sun replied that several vendors had requested the use of the OBJECT( ) operator because it will be included in the next major release of the SQL programming language. EJB QL was designed to be similar to SQL because SQL is the query language that is most familiar to developers, but this doesn’t mean it should include functions and operations that have no real meaning in Enterprise JavaBeans.

Lack of Support for Date

EJB QL doesn’t provide native support for the java.util.Date class. The java.util.Date class should be supported as a natural type in EJB QL. It should be possible, for example, to do comparisons with Date CMP fields and ...