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 ...