What's wrong with JPA QL, HQL and the concept of these query languages?

2010-04-23

I have a fundamental problem with the syntax of JPQL (or HQL for that matter). One of the design philosophies/principles was to have JPQL look as much as possible like SQL to make it easy for developers to understand and use this Object Oriented QL. It is actually that what is the problem...plus perhaps even more...

JPQL is not SQL

First a small detour: "For those of you who think that JPQL is a dirty part of ORM and just proves that you cannot live without SQL, i have to say you are incorrect. Whenever you have a big bag of "things" (such as XML elements, database rows, objects, constrains, concepts etc), you need a language to find one of these things. Of course an API will do as well, but these might turn out to be much to verbose and complex to use. So another language to query your bag of things is a perfect solution. To find XML nodes we use XQuery/XPath, to find data in an RDBMS we use SQL, to find Objects we use an object-oriented query language such as JPQL.",

Smells like SQL

Back to the main road: my problem with JPQL. My problem is it looks too much like SQL (recall this was one of the design goals). Why create am Object Oriented language and base it on a completely different languages that stems from a very different architecture and philosophy (the old OO vs the traditional Information-based approach). Why do we as OO people have to suffer and use an ancient language (1974, ok only 5 years after OO).

The SQL syntax is around the concept of data and its relations (count the number of SQL statements without implicit/ explicit inner or outer joins). The query language for OO should be around Objects and their associations.

Let lake a look at a couple of examples to stress my point

SELECT m FROM Member WHERE m.username=:name

What's with the "SELECT m from...", in 11 out of 10 cases you want an object (i'll get to the scalar queries later). Read it out in English "select m from member", what's that? Means you take the "m" from "member" and are left with "ember" (or rather "eber").

An improved JPQL?

JPQL should be something like (left out the alias, but might as well used it)

OBTAIN Member WITH username=:name

Often i need only one (the DISTINCT in SQL), we should have a syntax like

OBTAIN THE Member WITH username=:name

The above example would make "ALL" be the default as in "OBTAIN ALL Member" (seems to be an 's' missng And why am I using capitalization for the keywords?, another result of SQL, might as well throw away the camel-case and start using underscores again).

More fundamental problems

Now for some other problems with JPQL

  • What's with the UPDATE statement? Data/State changes due to behaviour not just because the data needs to changes! This is probably one of the worst parts of JPQL
  • Scalar queries: What is "SELECT m.email" doing in an object-oriented query language? Data itself has no meaning, the context of the data (object) and its behaviour (methods) give meaning to data. In fact why still make your fields private, as the above breaks object-oriented-encapsulation rules!

Breaking encapsulation

I must confess that there is even a bigger problem with an object oriented query language. One that is the actual fundamental problem, and one I can't do much about (it makes my head spin sometimes). The problem is that this object-oriented query language is based on the state/data of the objects. State is encapsulated and therefore kept private to the object. We should be able to change the internal structure of the objects, but now these private fields are referenced by queries. No properties don't solve this, because the problem here is that the OO QL is still based on data: Using properties solves some of the immediate programming problems which allows you to still change the internal private structure. But that was only a manifestation of the actual problem that we are using state of the objects in the OO QL...

Finding Objects by their behaviour?

Perhaps a true OO query language would be able to find object based on their behaviour in combination (bit like duck typing). Look for an object that can be assigned to a project and that is capable of "getting paid", instead of finding an Employee object where it's internal state "available" is true..

I guess here pragmatism comes into place, and the benefits outweigh the OO principles. However my experience tells me that one day/time a monster will rear its big and ugly head, and show us perhaps not to mess with fundamental rules.

But by that time all the projects that are benefiting from the pragmatic approach will have paid off and we just start using something new...I love the evolution in IT!

This article does not necessarily reflect the technical opinion of EDC4IT, but purely of the writer. If you want to discuss about this content, please use thecontact ussection of the site