Ejb Query Language Flaws

This is one of the all too many EjbFlaws.

It is supposed to allow the poor brainwashed programmers of ContainerManagedPersistence EntityBeans, to avoid using the SQL - which is supposedly too low level for the more abstract ObjectOriented thinking of the EJB-, and use instead a fancy mumbo jumbo, preciously called query language. Should the committee have bothered to avoid the CommitteesDontRead, they could have found however several significant papers, books, and even software that effectively runs and is useful, about query lanaguages based on the EntityRelationship? model, with which the said CMP EntityBeans have a kind of resemblance, and they could have tried at least a decent job of copy-and-paste.

The quality of the query language as drafted in the Ejb 2.0 specification is absolutely ridiculous. So far nobody from Sun or anyone else in the committee has bothered to properly analyze the correctness and/or the expressivity of the named query language. The only thing we find out is that it is entirely defined in its chapter of the standard, but the reality is that only its syntax is defined.

The standard avoids any paragraph that could be seriously called a definition, and instead uses a presentation style along the lines "informally, the abstract schema type of an entity bean can be characterized as follows ...", Abstract schema types are specific to the EJB QL data model while there is effectively no data model defined anywhere, and uses examples to "illustrate" the semantics of the language. Considering that all the examples used in the standard are based on a toy schema (as we often find in the books on SoftwareDevelopment), one might have a reasonable suspicion that EQL can be used only for toy applications. And even at a summary analysis it's easy to see that this is indeed the case.

The only thing that is good about the EQL is that it is meant to be translated at runtime into SQL. However it will be translated into a very small subset of SQL. Let's see what is missing from EQL:

aggregates.
subqueries of any kind , and consequently no proper IN, EXISTS, ALL , ANY.
selecting anything else other than a predefined entity, or a single attribute in the SELECT part.
tons of standard functions and operators for primitive data types.
string comparison, and don't even try to think about locales .
ORDER BY

and many many more things that are not necessarily standard (like the CASE operator in MSSQL and Sybase versus the DECODE(...) function in Oracle), but are routinely used in any serious application.

But even worse than the inability to express any query other than introductory examples, is the quality of the so called "data model". The said data model is based on entity, attributes and pointers, back to the good old days of network and hierarchical databases. As such the model isn't even as expressive as the old E-R model defined 25 years ago by Dr. Chen. As a parenthesis, DrCodd's opinion of the E-R model was that it was an example of imprecision and lack of formalism. Even if this was true, modern extended versions of the E-R are entirely formalized and analyzed in detail. But the problem with the so called "EJB QL data model" is that it's not even worth a 25 year old, informal model.

Counter arguments to the above are in EjbQueryLanguageDiscussion.

An evolving example to discuss the implications of EJB-QL is available at EjbTernaryRelationshipExample.