962 lines
35 KiB
XML
962 lines
35 KiB
XML
<chapter id="queryhql">
|
|
<title>HQL: The Hibernate Query Language</title>
|
|
|
|
<para>
|
|
Hibernate is equiped with an extremely powerful query language that (quite intentionally)
|
|
looks very much like SQL. But don't be fooled by the syntax; HQL is fully object-oriented,
|
|
understanding notions like inheritence, polymorphism and association.
|
|
</para>
|
|
|
|
<sect1 id="queryhql-casesensitivity">
|
|
<title>Case Sensitivity</title>
|
|
|
|
<para>
|
|
Queries are case-insensitive, except for names of Java classes and properties.
|
|
So <literal>SeLeCT</literal> is the same as
|
|
<literal>sELEct</literal> is the same as
|
|
<literal>SELECT</literal> but
|
|
<literal>org.hibernate.eg.FOO</literal> is not
|
|
<literal>org.hibernate.eg.Foo</literal> and
|
|
<literal>foo.barSet</literal> is not
|
|
<literal>foo.BARSET</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
This manual uses lowercase HQL keywords. Some users find queries with uppercase keywords
|
|
more readable, but we find this convention ugly when embedded in Java code.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-from">
|
|
<title>The from clause</title>
|
|
|
|
<para>
|
|
The simplest possible Hibernate query is of the form:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat]]></programlisting>
|
|
|
|
<para>
|
|
which simply returns all instances of the class <literal>eg.Cat</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
Most of the time, you will need to assign an <emphasis>alias</emphasis>, since
|
|
you will want to refer to the <literal>Cat</literal> in other parts of the
|
|
query.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat]]></programlisting>
|
|
|
|
<para>
|
|
This query assigns the alias <literal>cat</literal> to <literal>Cat</literal>
|
|
instances, so we could use that alias later in the query. The <literal>as</literal>
|
|
keyword is optional; we could also write:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat]]></programlisting>
|
|
|
|
<para>
|
|
Multiple classes may appear, resulting in a cartesian product or "cross" join.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from Formula, Parameter]]></programlisting>
|
|
<programlisting><![CDATA[from Formula as form, Parameter as param]]></programlisting>
|
|
|
|
<para>
|
|
It is considered good practice to name query aliases using an initial lowercase,
|
|
consistent with Java naming standards for local variables
|
|
(eg. <literal>domesticCat</literal>).
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-joins" revision="1">
|
|
<title>Associations and joins</title>
|
|
|
|
<para>
|
|
We may also assign aliases to associated entities, or even to elements of a collection of
|
|
values, using a <literal>join</literal>.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat
|
|
inner join cat.mate as mate
|
|
left outer join cat.kittens as kitten
|
|
|
|
from eg.Cat as cat left join cat.mate.kittens as kittens
|
|
|
|
from Formula form full join form.parameter param]]></programlisting>
|
|
|
|
<para>
|
|
The supported join types are borrowed from ANSI SQL
|
|
</para>
|
|
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para>
|
|
<literal>inner join</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>left outer join</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>right outer join</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>full join</literal> (not usually useful)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
The <literal>inner join</literal>, <literal>left outer join</literal> and
|
|
<literal>right outer join</literal> constructs may be abbreviated.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat
|
|
join cat.mate as mate
|
|
left join cat.kittens as kitten]]></programlisting>
|
|
|
|
<para>
|
|
In addition, a "fetch" join allows associations or collections of values to be
|
|
initialized along with their parent objects, using a single select. This is particularly
|
|
useful in the case of a collection. It effectively overrides the outer join and
|
|
lazy declarations of the mapping file for associations and collections. See
|
|
<xref linkend="performance-fetching"/> for more information.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat
|
|
inner join fetch cat.mate
|
|
left join fetch cat.kittens]]></programlisting>
|
|
|
|
<para>
|
|
A fetch join does not usually need to assign an alias, because the associated objects
|
|
should not be used in the <literal>where</literal> clause (or any other clause). Also,
|
|
the associated objects are not returned directly in the query results. Instead, they may
|
|
be accessed via the parent object.
|
|
</para>
|
|
|
|
<para>
|
|
Note that, in the current implementation, only one collection role may be fetched
|
|
in a query (everything else would be non-performant). Note also that the
|
|
<literal>fetch</literal> construct may not be used in queries called using
|
|
<literal>scroll()</literal> or <literal>iterate()</literal>. Finally, note that
|
|
<literal>full join fetch</literal> and <literal>right join fetch</literal> are not meaningful.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-select">
|
|
<title>The select clause</title>
|
|
|
|
<para>
|
|
The <literal>select</literal> clause picks which objects and properties to return in
|
|
the query result set. Consider:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select mate
|
|
from eg.Cat as cat
|
|
inner join cat.mate as mate]]></programlisting>
|
|
|
|
<para>
|
|
The query will select <literal>mate</literal>s of other <literal>Cat</literal>s.
|
|
Actually, you may express this query more compactly as:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat.mate from eg.Cat cat]]></programlisting>
|
|
|
|
<para>
|
|
You may even select collection elements, using the special <literal>elements</literal>
|
|
function. The following query returns all kittens of any cat.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select elements(cat.kittens) from eg.Cat cat]]></programlisting>
|
|
|
|
<para>
|
|
Queries may return properties of any value type including properties of component type:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat.name from eg.DomesticCat cat
|
|
where cat.name like 'fri%'
|
|
|
|
select cust.name.firstName from Customer as cust]]></programlisting>
|
|
|
|
<para>
|
|
Queries may return multiple objects and/or properties as an array of type
|
|
<literal>Object[]</literal>
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select mother, offspr, mate.name
|
|
from eg.DomesticCat as mother
|
|
inner join mother.mate as mate
|
|
left outer join mother.kittens as offspr]]></programlisting>
|
|
|
|
<para>
|
|
or as an actual typesafe Java object
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select new Family(mother, mate, offspr)
|
|
from eg.DomesticCat as mother
|
|
join mother.mate as mate
|
|
left join mother.kittens as offspr]]></programlisting>
|
|
|
|
<para>
|
|
assuming that the class <literal>Family</literal> has an appropriate constructor.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-aggregation">
|
|
<title>Aggregate functions</title>
|
|
|
|
<para>
|
|
HQL queries may even return the results of aggregate functions on properties:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select avg(cat.weight), sum(cat.weight), max(cat.weight), count(cat)
|
|
from eg.Cat cat]]></programlisting>
|
|
|
|
<para>
|
|
Collections may also appear inside aggregate functions in the <literal>select</literal>
|
|
clause.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat, count( elements(cat.kittens) )
|
|
from eg.Cat cat group by cat]]></programlisting>
|
|
|
|
<para>
|
|
The supported aggregate functions are
|
|
</para>
|
|
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para>
|
|
<literal>avg(...), sum(...), min(...), max(...)</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>count(*)</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>count(...), count(distinct ...), count(all...)</literal>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
The <literal>distinct</literal> and <literal>all</literal> keywords may be used and have
|
|
the same semantics as in SQL.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select distinct cat.name from eg.Cat cat
|
|
|
|
select count(distinct cat.name), count(cat) from eg.Cat cat]]></programlisting>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-polymorphism">
|
|
<title>Polymorphic queries</title>
|
|
|
|
<para>
|
|
A query like:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat]]></programlisting>
|
|
|
|
<para>
|
|
returns instances not only of <literal>Cat</literal>, but also of subclasses like
|
|
<literal>DomesticCat</literal>. Hibernate queries may name <emphasis>any</emphasis> Java
|
|
class or interface in the <literal>from</literal> clause. The query will return instances
|
|
of all persistent classes that extend that class or implement the interface. The following
|
|
query would return all persistent objects:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from java.lang.Object o]]></programlisting>
|
|
|
|
<para>
|
|
The interface <literal>Named</literal> might be implemented by various persistent
|
|
classes:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Named n, eg.Named m where n.name = m.name]]></programlisting>
|
|
|
|
<para>
|
|
Note that these last two queries will require more than one SQL <literal>SELECT</literal>. This
|
|
means that the <literal>order by</literal> clause does not correctly order the whole result set.
|
|
(It also means you can't call these queries using <literal>Query.scroll()</literal>.)
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-where">
|
|
<title>The where clause</title>
|
|
|
|
<para>
|
|
The <literal>where</literal> clause allows you to narrow the list of instances returned.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat where cat.name='Fritz']]></programlisting>
|
|
|
|
<para>
|
|
returns instances of <literal>Cat</literal> named 'Fritz'.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select foo
|
|
from eg.Foo foo, eg.Bar bar
|
|
where foo.startDate = bar.date]]></programlisting>
|
|
|
|
<para>
|
|
will return all instances of <literal>Foo</literal> for which
|
|
there exists an instance of <literal>bar</literal> with a
|
|
<literal>date</literal> property equal to the
|
|
<literal>startDate</literal> property of the
|
|
<literal>Foo</literal>. Compound path expressions make the
|
|
<literal>where</literal> clause extremely powerful. Consider:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat where cat.mate.name is not null]]></programlisting>
|
|
|
|
<para>
|
|
This query translates to an SQL query with a table (inner) join. If you were to write
|
|
something like
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Foo foo
|
|
where foo.bar.baz.customer.address.city is not null]]></programlisting>
|
|
|
|
<para>
|
|
you would end up with a query that would require four table joins in SQL.
|
|
</para>
|
|
|
|
<para>
|
|
The <literal>=</literal> operator may be used to compare not only properties, but also
|
|
instances:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat, eg.Cat rival where cat.mate = rival.mate
|
|
|
|
select cat, mate
|
|
from eg.Cat cat, eg.Cat mate
|
|
where cat.mate = mate]]></programlisting>
|
|
|
|
<para>
|
|
The special property (lowercase) <literal>id</literal> may be used to reference the
|
|
unique identifier of an object. (You may also use its property name.)
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as cat where cat.id = 123
|
|
|
|
from eg.Cat as cat where cat.mate.id = 69]]></programlisting>
|
|
|
|
<para>
|
|
The second query is efficient. No table join is required!
|
|
</para>
|
|
|
|
<para>
|
|
Properties of composite identifiers may also be used. Suppose <literal>Person</literal>
|
|
has a composite identifier consisting of <literal>country</literal> and
|
|
<literal>medicareNumber</literal>.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from bank.Person person
|
|
where person.id.country = 'AU'
|
|
and person.id.medicareNumber = 123456
|
|
|
|
from bank.Account account
|
|
where account.owner.id.country = 'AU'
|
|
and account.owner.id.medicareNumber = 123456]]></programlisting>
|
|
|
|
<para>
|
|
Once again, the second query requires no table join.
|
|
</para>
|
|
|
|
<para>
|
|
Likewise, the special property <literal>class</literal> accesses the discriminator value
|
|
of an instance in the case of polymorphic persistence. A Java class name embedded in the
|
|
where clause will be translated to its discriminator value.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat where cat.class = eg.DomesticCat]]></programlisting>
|
|
|
|
<para>
|
|
You may also specify properties of components or composite user types (and of components
|
|
of components, etc). Never try to use a path-expression that ends in a property of component
|
|
type (as opposed to a property of a component). For example, if <literal>store.owner</literal>
|
|
is an entity with a component <literal>address</literal>
|
|
</para>
|
|
|
|
<programlisting><![CDATA[store.owner.address.city // okay
|
|
store.owner.address // error!]]></programlisting>
|
|
|
|
<para>
|
|
An "any" type has the special properties <literal>id</literal> and <literal>class</literal>,
|
|
allowing us to express a join in the following way (where <literal>AuditLog.item</literal>
|
|
is a property mapped with <literal><any></literal>).
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.AuditLog log, eg.Payment payment
|
|
where log.item.class = 'eg.Payment' and log.item.id = payment.id]]></programlisting>
|
|
|
|
<para>
|
|
Notice that <literal>log.item.class</literal> and <literal>payment.class</literal>
|
|
would refer to the values of completely different database columns in the above query.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-expressions">
|
|
<title>Expressions</title>
|
|
|
|
<para>
|
|
Expressions allowed in the <literal>where</literal> clause include
|
|
most of the kind of things you could write in SQL:
|
|
</para>
|
|
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para>
|
|
mathematical operators <literal>+, -, *, /</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
binary comparison operators <literal>=, >=, <=, <>, !=, like</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
logical operations <literal>and, or, not</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
string concatenation ||
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
SQL scalar functions like <literal>upper()</literal> and
|
|
<literal>lower()</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Parentheses <literal>( )</literal> indicate grouping
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<literal>in</literal>,
|
|
<literal>between</literal>,
|
|
<literal>is null</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
JDBC IN parameters <literal>?</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
named parameters <literal>:name</literal>, <literal>:start_date</literal>, <literal>:x1</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
SQL literals <literal>'foo'</literal>, <literal>69</literal>, <literal>'1970-01-01 10:00:01.0'</literal>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Java <literal>public static final</literal> constants <literal>eg.Color.TABBY</literal>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
<literal>in</literal> and <literal>between</literal> may be used as follows:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.DomesticCat cat where cat.name between 'A' and 'B'
|
|
|
|
from eg.DomesticCat cat where cat.name in ( 'Foo', 'Bar', 'Baz' )]]></programlisting>
|
|
|
|
<para>
|
|
and the negated forms may be written
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.DomesticCat cat where cat.name not between 'A' and 'B'
|
|
|
|
from eg.DomesticCat cat where cat.name not in ( 'Foo', 'Bar', 'Baz' )]]></programlisting>
|
|
|
|
<para>
|
|
Likewise, <literal>is null</literal> and <literal>is not null</literal> may be used to test
|
|
for null values.
|
|
</para>
|
|
|
|
<para>
|
|
Booleans may be easily used in expressions by declaring HQL query substitutions in Hibernate
|
|
configuration:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[<property name="hibernate.query.substitutions">true 1, false 0</property>]]></programlisting>
|
|
|
|
<para>
|
|
This will replace the keywords <literal>true</literal> and <literal>false</literal> with the
|
|
literals <literal>1</literal> and <literal>0</literal> in the translated SQL from this HQL:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat where cat.alive = true]]></programlisting>
|
|
|
|
<para>
|
|
You may test the size of a collection with the special property <literal>size</literal>, or
|
|
the special <literal>size()</literal> function.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat cat where cat.kittens.size > 0
|
|
|
|
from eg.Cat cat where size(cat.kittens) > 0]]></programlisting>
|
|
|
|
<para>
|
|
For indexed collections, you may refer to the minimum and maximum indices using
|
|
<literal>minIndex</literal> and <literal>maxIndex</literal>. Similarly, you may refer to the
|
|
minimum and maximum elements of a collection of basic type using <literal>minElement</literal>
|
|
and <literal>maxElement</literal>.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from Calendar cal where cal.holidays.maxElement > current date]]></programlisting>
|
|
|
|
<para>
|
|
There are also functional forms (which, unlike the constructs above, are not case sensitive):
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from Order order where maxindex(order.items) > 100
|
|
|
|
from Order order where minelement(order.items) > 10000]]></programlisting>
|
|
|
|
<para>
|
|
The SQL functions <literal>any, some, all, exists, in</literal> are supported when passed the element
|
|
or index set of a collection (<literal>elements</literal> and <literal>indices</literal> functions)
|
|
or the result of a subquery (see below).
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select mother from eg.Cat as mother, eg.Cat as kit
|
|
where kit in elements(foo.kittens)
|
|
|
|
select p from eg.NameList list, eg.Person p
|
|
where p.name = some elements(list.names)
|
|
|
|
from eg.Cat cat where exists elements(cat.kittens)
|
|
|
|
from eg.Player p where 3 > all elements(p.scores)
|
|
|
|
from eg.Show show where 'fizard' in indices(show.acts)]]></programlisting>
|
|
|
|
<para>
|
|
Note that these constructs - <literal>size</literal>, <literal>elements</literal>,
|
|
<literal>indices</literal>, <literal>minIndex</literal>, <literal>maxIndex</literal>,
|
|
<literal>minElement</literal>, <literal>maxElement</literal> - have certain usage
|
|
restrictions:
|
|
</para>
|
|
|
|
<itemizedlist spacing="compact">
|
|
<listitem>
|
|
<para>
|
|
in a <literal>where</literal> clause: only for databases with subselects
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
in a <literal>select</literal> clause: only <literal>elements</literal> and
|
|
<literal>indices</literal> make sense
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>
|
|
Elements of indexed collections (arrays, lists, maps) may be referred to by
|
|
index (in a where clause only):
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from Order order where order.items[0].id = 1234
|
|
|
|
select person from Person person, Calendar calendar
|
|
where calendar.holidays['national day'] = person.birthDay
|
|
and person.nationality.calendar = calendar
|
|
|
|
select item from Item item, Order order
|
|
where order.items[ order.deliveredItemIndices[0] ] = item and order.id = 11
|
|
|
|
select item from Item item, Order order
|
|
where order.items[ maxindex(order.items) ] = item and order.id = 11]]></programlisting>
|
|
|
|
<para>
|
|
The expression inside <literal>[]</literal> may even be an arithmetic expression.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select item from Item item, Order order
|
|
where order.items[ size(order.items) - 1 ] = item]]></programlisting>
|
|
|
|
<para>
|
|
HQL also provides the built-in <literal>index()</literal> function, for elements of
|
|
a one-to-many association or collection of values.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select item, index(item) from Order order
|
|
join order.items item
|
|
where index(item) < 5]]></programlisting>
|
|
|
|
<para>
|
|
Scalar SQL functions supported by the underlying database may be used
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.DomesticCat cat where upper(cat.name) like 'FRI%']]></programlisting>
|
|
|
|
<para>
|
|
If you are not yet convinced by all this, think how much longer and less readable the
|
|
following query would be in SQL:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cust
|
|
from Product prod,
|
|
Store store
|
|
inner join store.customers cust
|
|
where prod.name = 'widget'
|
|
and store.location.name in ( 'Melbourne', 'Sydney' )
|
|
and prod = all elements(cust.currentOrder.lineItems)]]></programlisting>
|
|
|
|
<para>
|
|
<emphasis>Hint:</emphasis> something like
|
|
</para>
|
|
|
|
<programlisting><![CDATA[SELECT cust.name, cust.address, cust.phone, cust.id, cust.current_order
|
|
FROM customers cust,
|
|
stores store,
|
|
locations loc,
|
|
store_customers sc,
|
|
product prod
|
|
WHERE prod.name = 'widget'
|
|
AND store.loc_id = loc.id
|
|
AND loc.name IN ( 'Melbourne', 'Sydney' )
|
|
AND sc.store_id = store.id
|
|
AND sc.cust_id = cust.id
|
|
AND prod.id = ALL(
|
|
SELECT item.prod_id
|
|
FROM line_items item, orders o
|
|
WHERE item.order_id = o.id
|
|
AND cust.current_order = o.id
|
|
)]]></programlisting>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-ordering">
|
|
<title>The order by clause</title>
|
|
|
|
<para>
|
|
The list returned by a query may be ordered by any property of a returned class or components:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.DomesticCat cat
|
|
order by cat.name asc, cat.weight desc, cat.birthdate]]></programlisting>
|
|
|
|
<para>
|
|
The optional <literal>asc</literal> or <literal>desc</literal> indicate ascending or descending order
|
|
respectively.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-grouping">
|
|
<title>The group by clause</title>
|
|
|
|
<para>
|
|
A query that returns aggregate values may be grouped by any property of a returned class or components:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat.color, sum(cat.weight), count(cat)
|
|
from eg.Cat cat
|
|
group by cat.color
|
|
|
|
select foo.id, avg( elements(foo.names) ), max( indices(foo.names) )
|
|
from eg.Foo foo
|
|
group by foo.id]]></programlisting>
|
|
|
|
<para>
|
|
Note: You may use the <literal>elements</literal> and <literal>indices</literal> constructs
|
|
inside a select clause, even on databases with no subselects.
|
|
</para>
|
|
|
|
<para>
|
|
A <literal>having</literal> clause is also allowed.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat.color, sum(cat.weight), count(cat)
|
|
from eg.Cat cat
|
|
group by cat.color
|
|
having cat.color in (eg.Color.TABBY, eg.Color.BLACK)]]></programlisting>
|
|
|
|
<para>
|
|
SQL functions and aggregate functions are allowed in the <literal>having</literal>
|
|
and <literal>order by</literal> clauses, if supported by the underlying database (ie.
|
|
not in MySQL).
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select cat
|
|
from eg.Cat cat
|
|
join cat.kittens kitten
|
|
group by cat
|
|
having avg(kitten.weight) > 100
|
|
order by count(kitten) asc, sum(kitten.weight) desc]]></programlisting>
|
|
|
|
<para>
|
|
Note that neither the <literal>group by</literal> clause nor the
|
|
<literal>order by</literal> clause may contain arithmetic expressions.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-subqueries">
|
|
<title>Subqueries</title>
|
|
|
|
<para>
|
|
For databases that support subselects, Hibernate supports subqueries within queries. A subquery must
|
|
be surrounded by parentheses (often by an SQL aggregate function call). Even correlated subqueries
|
|
(subqueries that refer to an alias in the outer query) are allowed.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from eg.Cat as fatcat
|
|
where fatcat.weight > (
|
|
select avg(cat.weight) from eg.DomesticCat cat
|
|
)
|
|
|
|
from eg.DomesticCat as cat
|
|
where cat.name = some (
|
|
select name.nickName from eg.Name as name
|
|
)
|
|
|
|
from eg.Cat as cat
|
|
where not exists (
|
|
from eg.Cat as mate where mate.mate = cat
|
|
)
|
|
|
|
from eg.DomesticCat as cat
|
|
where cat.name not in (
|
|
select name.nickName from eg.Name as name
|
|
)]]></programlisting>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-examples">
|
|
<title>HQL examples</title>
|
|
|
|
<para>
|
|
Hibernate queries can be quite powerful and complex. In fact, the power of the query language
|
|
is one of Hibernate's main selling points. Here are some example queries very similar to queries
|
|
that I used on a recent project. Note that most queries you will write are much simpler than these!
|
|
</para>
|
|
|
|
<para>
|
|
The following query returns the order id, number of items and total value of the order for all
|
|
unpaid orders for a particular customer and given minimum total value, ordering the results by
|
|
total value. In determining the prices, it uses the current catalog. The resulting SQL query,
|
|
against the <literal>ORDER</literal>, <literal>ORDER_LINE</literal>, <literal>PRODUCT</literal>,
|
|
<literal>CATALOG</literal> and <literal>PRICE</literal> tables has four inner joins and an
|
|
(uncorrelated) subselect.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select order.id, sum(price.amount), count(item)
|
|
from Order as order
|
|
join order.lineItems as item
|
|
join item.product as product,
|
|
Catalog as catalog
|
|
join catalog.prices as price
|
|
where order.paid = false
|
|
and order.customer = :customer
|
|
and price.product = product
|
|
and catalog.effectiveDate < sysdate
|
|
and catalog.effectiveDate >= all (
|
|
select cat.effectiveDate
|
|
from Catalog as cat
|
|
where cat.effectiveDate < sysdate
|
|
)
|
|
group by order
|
|
having sum(price.amount) > :minAmount
|
|
order by sum(price.amount) desc]]></programlisting>
|
|
|
|
<para>
|
|
What a monster! Actually, in real life, I'm not very keen on subqueries, so my query was
|
|
really more like this:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select order.id, sum(price.amount), count(item)
|
|
from Order as order
|
|
join order.lineItems as item
|
|
join item.product as product,
|
|
Catalog as catalog
|
|
join catalog.prices as price
|
|
where order.paid = false
|
|
and order.customer = :customer
|
|
and price.product = product
|
|
and catalog = :currentCatalog
|
|
group by order
|
|
having sum(price.amount) > :minAmount
|
|
order by sum(price.amount) desc]]></programlisting>
|
|
|
|
<para>
|
|
The next query counts the number of payments in each status, excluding all payments in the
|
|
<literal>AWAITING_APPROVAL</literal> status where the most recent status change was made by the
|
|
current user. It translates to an SQL query with two inner joins and a correlated subselect
|
|
against the <literal>PAYMENT</literal>, <literal>PAYMENT_STATUS</literal> and
|
|
<literal>PAYMENT_STATUS_CHANGE</literal> tables.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select count(payment), status.name
|
|
from Payment as payment
|
|
join payment.currentStatus as status
|
|
join payment.statusChanges as statusChange
|
|
where payment.status.name <> PaymentStatus.AWAITING_APPROVAL
|
|
or (
|
|
statusChange.timeStamp = (
|
|
select max(change.timeStamp)
|
|
from PaymentStatusChange change
|
|
where change.payment = payment
|
|
)
|
|
and statusChange.user <> :currentUser
|
|
)
|
|
group by status.name, status.sortOrder
|
|
order by status.sortOrder]]></programlisting>
|
|
|
|
<para>
|
|
If I would have mapped the <literal>statusChanges</literal> collection as a list, instead of a set,
|
|
the query would have been much simpler to write.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select count(payment), status.name
|
|
from Payment as payment
|
|
join payment.currentStatus as status
|
|
where payment.status.name <> PaymentStatus.AWAITING_APPROVAL
|
|
or payment.statusChanges[ maxIndex(payment.statusChanges) ].user <> :currentUser
|
|
group by status.name, status.sortOrder
|
|
order by status.sortOrder]]></programlisting>
|
|
|
|
<para>
|
|
The next query uses the MS SQL Server <literal>isNull()</literal> function to return all
|
|
the accounts and unpaid payments for the organization to which the current user belongs.
|
|
It translates to an SQL query with three inner joins, an outer join and a subselect against
|
|
the <literal>ACCOUNT</literal>, <literal>PAYMENT</literal>, <literal>PAYMENT_STATUS</literal>,
|
|
<literal>ACCOUNT_TYPE</literal>, <literal>ORGANIZATION</literal> and
|
|
<literal>ORG_USER</literal> tables.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select account, payment
|
|
from Account as account
|
|
left outer join account.payments as payment
|
|
where :currentUser in elements(account.holder.users)
|
|
and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID)
|
|
order by account.type.sortOrder, account.accountNumber, payment.dueDate]]></programlisting>
|
|
|
|
<para>
|
|
For some databases, we would need to do away with the (correlated) subselect.
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select account, payment
|
|
from Account as account
|
|
join account.holder.users as user
|
|
left outer join account.payments as payment
|
|
where :currentUser = user
|
|
and PaymentStatus.UNPAID = isNull(payment.currentStatus.name, PaymentStatus.UNPAID)
|
|
order by account.type.sortOrder, account.accountNumber, payment.dueDate]]></programlisting>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="queryhql-tipstricks">
|
|
<title>Tips & Tricks</title>
|
|
|
|
<para>
|
|
You can count the number of query results without actually returning them:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[( (Integer) session.iterate("select count(*) from ....").next() ).intValue()]]></programlisting>
|
|
|
|
<para>
|
|
To order a result by the size of a collection, use the following query:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select usr.id, usr.name
|
|
from User as usr
|
|
left join usr.messages as msg
|
|
group by usr.id, usr.name
|
|
order by count(msg)]]></programlisting>
|
|
|
|
<para>
|
|
If your database supports subselects, you can place a condition upon selection
|
|
size in the where clause of your query:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[from User usr where size(usr.messages) >= 1]]></programlisting>
|
|
|
|
<para>
|
|
If your database doesn't support subselects, use the following query:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select usr.id, usr.name
|
|
from User usr.name
|
|
join usr.messages msg
|
|
group by usr.id, usr.name
|
|
having count(msg) >= 1]]></programlisting>
|
|
|
|
<para>
|
|
As this solution can't return a <literal>User</literal> with zero messages
|
|
because of the inner join, the following form is also useful:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[select usr.id, usr.name
|
|
from User as usr
|
|
left join usr.messages as msg
|
|
group by usr.id, usr.name
|
|
having count(msg) = 0]]></programlisting>
|
|
|
|
<para>
|
|
Properties of a JavaBean can be bound to named query parameters:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[Query q = s.createQuery("from foo in class Foo where foo.name=:name and foo.size=:size");
|
|
q.setProperties(fooBean); // fooBean has getName() and getSize()
|
|
List foos = q.list();]]></programlisting>
|
|
|
|
<para>
|
|
Collections are pageable by using the <literal>Query</literal> interface with a filter:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[Query q = s.createFilter( collection, "" ); // the trivial filter
|
|
q.setMaxResults(PAGE_SIZE);
|
|
q.setFirstResult(PAGE_SIZE * pageNumber);
|
|
List page = q.list();]]></programlisting>
|
|
|
|
<para>
|
|
Collection elements may be ordered or grouped using a query filter:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[Collection orderedCollection = s.filter( collection, "order by this.amount" );
|
|
Collection counts = s.filter( collection, "select this.type, count(this) group by this.type" );]]></programlisting>
|
|
|
|
<para>
|
|
You can find the size of a collection without initializing it:
|
|
</para>
|
|
|
|
<programlisting><![CDATA[( (Integer) session.iterate("select count(*) from ....").next() ).intValue();]]></programlisting>
|
|
|
|
</sect1>
|
|
|
|
</chapter>
|
|
|