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 use of the
operator is unnecessary and
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
operator provides little real value during query translation. In
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
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.
Soon after you begin using EJB QL, you will probably realize that
it’s missing a major component, the
BY clause. Requesting ordered lists is extremely important in any query language, and most major query ...