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 ...
Get Enterprise JavaBeans, Fourth Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.