Ejb Query Language

A language used to for component developers to write queries for Container Managed Beans. The queries will then be translated (either at runtime or deployment time) into a query language appropriate for the persistence layer used by the EJB (see EnterpriseJavaBeans) container the EJB is deployed into (typically StructuredQueryLanguage - SQL, as most EJBs are deployed against relational databases).

The EJB Query Language is defined in the Enterprise Java Beans 2.0 Specification from SunMicrosystems.

EQL bears little to no resemblance to SQL (which is meant to be a relational querying language). Instead, it's a variant of an ObjectQueryLanguage, which makes sense as Entities are objects. If you insist on thinking that Entities are merely wrappers around database tables, then you'll probably find EQL to be a bit simplistic for your needs.

Well since somebody just disagreed by deleting, let's moderately state that EQL suffers of all too many EjbQueryLanguageFlaws.

If it is a flaw in itself is somewhat debatable, but there's enough evidence to sustain that the whole point of EQL design is to be safely and comfortably translated to SQL. In which case it is a flawed idea because it is a redundant language. And because the quasi-majority if not all application servers are simply EQL to SQL translators (any counter-example?), this looks indeed to be the case. Achieving 100% redundancy with SQL seems to be the primary goal of current EQL specification, of course they have to work a lot more to get to this prized "trophy".

It is also safe to say that EQL is perfectly isomorphic (at EJB2.0 level) with a very small subset of SQL, it doesn't add any more expressive power, and it doesn't come with any real innovation either.

EQL is not too simplistic from the "purely relational" point of view, but simply from a practical problem solving point of view, as there are many things that are awkwardly expressed under EQL/CMP Entity model, and other things that cannot be solved at all as in EjbTernaryRelationshipExample, and that's the biggest problem of them all.

The more subtle problem is that the Sun committee constructed the Entity/EQL model in what looks like a reasonable disregard of more than 25 years of research in EntityRelationship? modeling, thus it is ridiculous to claim that EQL is what it is because it is supposed to query entities instead of relations. Well, the disregard for the relational model principles I guess should be self-evident, but the disregard for ER can be seen by the fact that ContainerManagedRelationship?s only support binary relations while any ER basically works with n-ary relationships, and for over 15 years already ER also includes higher order relationships ( relationship whose participants may other relationships not only entities). Also, no reference work in ER is cited or just followed by the authors of EJB specification. Basically in EQL version of ER a relationship is the side-effect of the availability of pointers (or collection of pointers) from one entity to another. This is in no way proper ER.

By the way, why don't these committees bother to properly reference relevant previous work? It is like they invent every little squared wheel.

There are enough mathematically sound query languages over variation of EntityRelationship? data models. They are well documented and understood and some of them running in real software systems, if only the committee knew where and how to read them, and that it was supposed to read them to begin with. --CostinCozianu

Comments on flaws moved to EjbQueryLanguageFlaws, largely because they were biased. DisagreeByMovingAside?.

Counter arguments to the EjbQueryLanguageFlaws are in EjbQueryLanguageDiscussion.

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

Does the ObjectRelationalPsychologicalMismatch also play a role here?

CategoryEjb