Hibernate example source code file (query_hql.xml)

This example Hibernate source code file (query_hql.xml) is included in the DevDaily.com "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" ^TM.

Java - Hibernate tags/keywords

cat, cat, cdata, cdata, domesticcat, hql, java, person, sql, sql, the, the, this, you

The Hibernate query_hql.xml source code

<?xml version='1.0' encoding="UTF-8"?>
<!--
  ~ Hibernate, Relational Persistence for Idiomatic Java
  ~
  ~ Copyright (c) 2008, Red Hat Middleware LLC or third-party contributors as
  ~ indicated by the @author tags or express copyright attribution
  ~ statements applied by the authors.  All third-party contributions are
  ~ distributed under license by Red Hat Middleware LLC.
  ~
  ~ This copyrighted material is made available to anyone wishing to use, modify,
  ~ copy, or redistribute it subject to the terms and conditions of the GNU
  ~ Lesser General Public License, as published by the Free Software Foundation.
  ~
  ~ This program is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
  ~ for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public License
  ~ along with this distribution; if not, write to:
  ~ Free Software Foundation, Inc.
  ~ 51 Franklin Street, Fifth Floor
  ~ Boston, MA  02110-1301  USA
  -->

<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "../HIBERNATE_-_Relational_Persistence_for_Idiomatic_Java.ent">
%BOOK_ENTITIES;

]>

<chapter id="queryhql" revision="1">
    <title>HQL: The Hibernate Query Language

    <para>
        Hibernate uses a powerful query language (HQL) that is similar in appearance to
        SQL. Compared with SQL, however, HQL is fully object-oriented
        and understands notions like inheritance, polymorphism and association.
    </para>

    <section id="queryhql-casesensitivity">
        <title>Case Sensitivity

        <para>
            With the exception of names of Java classes and properties, queries are case-insensitive.
            So <literal>SeLeCT is the same as
            <literal>sELEct is the same as
            <literal>SELECT, but
            <literal>org.hibernate.eg.FOO is not
            <literal>org.hibernate.eg.Foo, and
            <literal>foo.barSet is not
            <literal>foo.BARSET.
        </para>

        <para>
            This manual uses lowercase HQL keywords. Some users find queries with uppercase keywords
            more readable, but this convention is unsuitable for queries embedded in Java code.
        </para>

    </section>

    <section id="queryhql-from">
        <title>The from clause

        <para>
            The simplest possible Hibernate query is of the form:
        </para>

        <programlisting>

        <para>
            This returns all instances of the class <literal>eg.Cat.
            You do not usually need to qualify the class name, since <literal>auto-import
            is the default. For example:
        </para>

        <programlisting>

        <para>
            
            In order to refer to the <literal>Cat in other parts of the
            query, you will need to assign an <emphasis>alias. For example:
        </para>

        <programlisting>

        <para>
            This query assigns the alias <literal>cat to Cat
            instances, so you can use that alias later in the query. The <literal>as
            keyword is optional. You could also write:
        </para>

        <programlisting>

        <para>
            Multiple classes can appear, resulting in a cartesian product or "cross" join.
        </para>

        <programlisting>
        <programlisting>

        <para>
            It is good practice to name query aliases using an initial lowercase as this is
            consistent with Java naming standards for local variables
            (e.g. <literal>domesticCat).
        </para>

    </section>

    <section id="queryhql-joins" revision="2">
        <title>Associations and joins

        <para>
            You can also assign aliases to associated entities or to elements of a
            collection of values using a <literal>join. For example:
        </para>

        <programlisting>

        <programlisting>

        <programlisting>

        <para>
            The supported join types are borrowed from ANSI SQL:
        </para>

        <itemizedlist spacing="compact">
            <listitem>
                <para>
                    <literal>inner join
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>left outer join
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>right outer join
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>full join (not usually useful)
                </para>
            </listitem>
        </itemizedlist>

        <para>
            The <literal>inner join, left outer join and
            <literal>right outer join constructs may be abbreviated.
        </para>

        <programlisting>

        <para>
            You may supply extra join conditions using the HQL <literal>with
            keyword.
        </para>

        <programlisting></programlisting>

        <para>
            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>

        <para>
            A fetch join does not usually need to assign an alias, because the associated objects
            should not be used in the <literal>where clause (or any other clause). 
            The associated objects are also not returned directly in the query results. Instead, they may
            be accessed via the parent object. The only reason you might need an alias is if you are
            recursively join fetching a further collection:
        </para>

        <programlisting>

        <para>
            The <literal>fetch construct cannot be used in queries called using
            <literal>iterate() (though scroll() can be used). 
            <literal>Fetch should be used together with setMaxResults() or
            <literal>setFirstResult(), as these operations are based on the result rows which
            usually contain duplicates for eager collection fetching, hence, the number of rows is not what
            you would expect.
            <literal>Fetch should also not be used together with impromptu with condition.
            It is possible to create a cartesian product by join fetching more than one collection in a
            query, so take care in this case. Join fetching multiple collection roles can produce
            unexpected results for bag mappings, so user discretion is advised when formulating queries in this
            case. Finally, note that <literal>full join fetch and right join fetch
            are not meaningful.
        </para>

        <para>
            If you are using property-level lazy fetching (with bytecode instrumentation), it is
            possible to force Hibernate to fetch the lazy properties in the first query immediately
            using <literal>fetch all properties.
        </para>

        <programlisting>
        <programlisting>

    </section>

    <section id="queryhql-joins-forms">
        <title>Forms of join syntax

	    <para>
		    HQL supports two forms of association joining: <literal>implicit and explicit.
		</para>

	    <para>
		    The queries shown in the previous section all use the <literal>explicit form, that is, where
		    the join keyword is explicitly used in the from clause.  This is the recommended form.
	    </para>

	    <para>
		    The <literal>implicit form does not use the join keyword.  Instead, the
		    associations are "dereferenced" using dot-notation.  <literal>implicit joins
		    can appear in any of the HQL clauses.  <literal>implicit join result
		    in inner joins in the resulting SQL statement.
	    </para>

        <programlisting>
	</section>

    <section id="queryhql-identifier-property">
        <title>Referring to identifier property

        <para>
            There are 2 ways to refer to an entity's identifier property:
        </para>
        <itemizedlist spacing="compact">
            <listitem>
                <para>
                    The special property (lowercase) <literal>id may be used to reference the identifier
                    property of an entity <emphasis>provided that the entity does not define a non-identifier property
                    named id</emphasis>.
                </para>
            </listitem>
            <listitem>
                <para>
                    If the entity defines a named identifier property, you can use that property name.
                </para>
            </listitem>
        </itemizedlist>

        <para>
            References to composite identifier properties follow the same naming rules. If the
            entity has a non-identifier property named id, the composite identifier property can only
            be referenced by its defined named. Otherwise, the special <literal>id property
            can be used to reference the identifier property.
        </para>

	<important>
        <para>
            Please note that, starting in version 3.2.2, this has changed significantly. In previous versions,
            <literal>id  always referred to the identifier property
            regardless of its actual name.  A ramification of that decision was that non-identifier
            properties named <literal>id could never be referenced in Hibernate queries.
        </para>
	</important>  

  </section>

    <section id="queryhql-select">
        <title>The select clause

        <para>
            The <literal>select clause picks which objects and properties to return in
            the query result set. Consider the following:
        </para>

        <programlisting>

        <para>
            The query will select <literal>mates of other Cats.
            You can express this query more compactly as:
        </para>

        <programlisting>

        <para>
            Queries can return properties of any value type including properties of component type:
        </para>

        <programlisting>

        <programlisting>

        <para>
            Queries can return multiple objects and/or properties as an array of type
            <literal>Object[]:
        </para>

        <programlisting>

        <para>
            Or as a <literal>List:
        </para>

        <programlisting>

        <para>
            Or - assuming that the class <literal>Family has an appropriate constructor - as an actual typesafe Java object:
        </para>

        <programlisting>

      
        <para>
            You can assign aliases to selected expressions using <literal>as:
        </para>

        <programlisting>

        <para>
            This is most useful when used together with <literal>select new map:
        </para>

        <programlisting>

        <para>
            This query returns a <literal>Map from aliases to selected values.
        </para>

    </section>

    <section id="queryhql-aggregation">
        <title>Aggregate functions

        <para>
            HQL queries can even return the results of aggregate functions on properties:
        </para>

        <programlisting>

<!-- NO LONGER SUPPORTED
        <para>
            Collections can also appear inside aggregate functions in the <literal>select
            clause.
        </para>

        <programlisting>
-->

        <para>
            The supported aggregate functions are:
        </para>

        <itemizedlist spacing="compact">
            <listitem>
                <para>
                    <literal>avg(...), sum(...), min(...), max(...)
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>count(*)
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>count(...), count(distinct ...), count(all...)
                </para>
            </listitem>
        </itemizedlist>

        <para>
            You can use arithmetic operators, concatenation, and recognized SQL functions
            in the select clause:
        </para>

        <programlisting>

        <programlisting>

        <para>
            The <literal>distinct and all keywords can be used and
            have the same semantics as in SQL.
        </para>

        <programlisting>

    </section>

    <section id="queryhql-polymorphism">
        <title>Polymorphic queries

        <para>
            A query like:
        </para>

        <programlisting>

        <para>
            returns instances not only of <literal>Cat, but also of subclasses like
            <literal>DomesticCat. Hibernate queries can name any Java
            class or interface in the <literal>from 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>

        <para>
            The interface <literal>Named might be implemented by various persistent
            classes:
        </para>

        <programlisting>

        <para>
            These last two queries will require more than one SQL <literal>SELECT. This
            means that the <literal>order by clause does not correctly order the whole result set.
            It also means you cannot call these queries using <literal>Query.scroll().
        </para>

    </section>

    <section id="queryhql-where" revision="1">
        <title>The where clause

        <para>
            The <literal>where clause allows you to refine the list of instances returned.
            If no alias exists, you can refer to properties by name:
        </para>

        <programlisting>

        <para>
        	If there is an alias, use a qualified property name:
        </para>

        <programlisting>

        <para>
            This returns instances of <literal>Cat named 'Fritz'.
        </para>

		<para>
			The following query:
        </para>
        <programlisting>

        <para>
            returns all instances of <literal>Foo with an
            instance of <literal>bar with a
            <literal>date property equal to the
            <literal>startDate property of the
            <literal>Foo. Compound path expressions make the
            <literal>where clause extremely powerful. Consider the following:
        </para>

        <programlisting>

        <para>
            This query translates to an SQL query with a table (inner) join. For example:
            
        </para>

        <programlisting>

        <para>
            would result in a query that would require four table joins in SQL.
        </para>

        <para>
            The <literal>= operator can be used to compare not only properties, but also
            instances:
        </para>

        <programlisting>

        <programlisting>

        <para>
            The special property (lowercase) <literal>id can be used to reference the
            unique identifier of an object. See <xref linkend="queryhql-identifier-property"/>
            for more information.
        </para>

        <programlisting>

        <para>
            The second query is efficient and does not require a table join.
        </para>

        <para>
            Properties of composite identifiers can also be used. Consider the following example where <literal>Person
            has composite identifiers consisting of <literal>country and
            <literal>medicareNumber:
        </para>

        <programlisting>

        <programlisting>

        <para>
            Once again, the second query does not require a table join.
        </para>
	
	<para>
	See <xref linkend="queryhql-identifier-property"/>
            for more information regarding referencing identifier properties)
	</para>
        
	<para>
            The special property <literal>class 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>

        <para>
            You can also use components or composite user types, or properties of said
            component types. See <xref linkend="queryhql-components"/> for more information.
        </para>

        <para>
            An "any" type has the special properties <literal>id and class that allows you
            to express a join in the following way (where <literal>AuditLog.item
            is a property mapped with <literal><any>):
        </para>

        <programlisting>

        <para>
            The <literal>log.item.class and payment.class
            would refer to the values of completely different database columns in the above query.
        </para>

    </section>

    <section id="queryhql-expressions">
        <title>Expressions

        <para>
            Expressions used in the <literal>where clause include the following:
            
        </para>

        <itemizedlist spacing="compact">
            <listitem>
                <para>
                    mathematical operators: <literal>+, -, *, /
                </para>
            </listitem>
            <listitem>
                <para>
                    binary comparison operators: <literal>=, >=, <=, <>, !=, like
                </para>
            </listitem>
            <listitem>
                <para>
                    logical operations <literal>and, or, not
                </para>
            </listitem>
            <listitem>
                <para>
                    Parentheses <literal>( ) that indicates grouping
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>in,
                    <literal>not in,
                    <literal>between,
                    <literal>is null,
                    <literal>is not null,
                    <literal>is empty,
                    <literal>is not empty,
                    <literal>member of and
                    <literal>not member of
                </para>
            </listitem>
            <listitem>
                <para>
                	"Simple" case, <literal>case ... when ... then ... else ... end, and
                    "searched" case, <literal>case when ... then ... else ... end
                </para>
            </listitem>
            <listitem>
                <para>
                    string concatenation <literal>...||... or concat(...,...)
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>current_date(), current_time(), and
                    <literal>current_timestamp()
                </para>
            </listitem>
            <listitem>
                <para>
					<literal>second(...), minute(...),
					<literal>hour(...), day(...),
					<literal>month(...), and year(...)
                </para>
            </listitem>
            <listitem>
                <para>
                    Any function or operator defined by EJB-QL 3.0: <literal>substring(), trim(),
                    lower(), upper(), length(), locate(), abs(), sqrt(), bit_length(), mod()</literal>
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>coalesce() and nullif()
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>str() for converting numeric or temporal values to a
                    readable string
                </para>
            </listitem>
            <listitem>
                <para>
                    <literal>cast(... as ...), where the second argument is the name of
                    a Hibernate type, and <literal>extract(... from ...) if ANSI
                    <literal>cast() and extract() is supported by
                    the underlying database
                </para>
            </listitem>
            <listitem>
                <para>
                    the HQL <literal>index() function, that applies to aliases of
                    a joined indexed collection
                </para>
            </listitem>
            <listitem>
                <para>
                    HQL functions that take collection-valued path expressions: <literal>size(),
                    minelement(), maxelement(), minindex(), maxindex()</literal>, along with the
                    special <literal>elements() and indices functions
                    that can be quantified using <literal>some, all, exists, any, in.
                </para>
            </listitem>
            <listitem>
                <para>
                    Any database-supported SQL scalar function like <literal>sign(),
                    <literal>trunc(), rtrim(), and sin()
                </para>
            </listitem>
            <listitem>
                <para>
                    JDBC-style positional parameters <literal>?
                </para>
            </listitem>
            <listitem>
                <para>
                    named parameters <literal>:name, :start_date, and :x1
                </para>
            </listitem>
            <listitem>
                <para>
                    SQL literals <literal>'foo', 69, 6.66E+2,
                    <literal>'1970-01-01 10:00:01.0'
                </para>
            </listitem>
            <listitem>
                <para>
                    Java <literal>public static final constants eg.Color.TABBY
                </para>
            </listitem>
        </itemizedlist>

        <para>
            <literal>in and between can be used as follows:
        </para>

        <programlisting>

        <programlisting>

        <para>
            The negated forms can be written as follows:
        </para>

        <programlisting>

        <programlisting>

        <para>
            Similarly, <literal>is null and is not null can be used to test
            for null values.
        </para>

        <para>
            Booleans can be easily used in expressions by declaring HQL query substitutions in Hibernate
            configuration:
        </para>

        <programlisting>true 1, false 0]]>

        <para>
            This will replace the keywords <literal>true and false with the
            literals <literal>1 and 0 in the translated SQL from this HQL:
        </para>

        <programlisting>

        <para>
            You can test the size of a collection with the special property <literal>size or
            the special <literal>size() function.
        </para>

        <programlisting> 0]]>

        <programlisting> 0]]>

        <para>
            For indexed collections, you can refer to the minimum and maximum indices using
            <literal>minindex and maxindex functions. Similarly,
            you can refer to the minimum and maximum elements of a collection of basic type
            using the <literal>minelement and maxelement
            functions. For example:
        </para>

        <programlisting> current_date]]>

        <programlisting> 100]]>

        <programlisting> 10000]]>

        <para>
            The SQL functions <literal>any, some, all, exists, in are supported when passed the element
            or index set of a collection (<literal>elements and indices functions)
            or the result of a subquery (see below):
        </para>

        <programlisting>

        <programlisting>

        <programlisting>

        <programlisting> all elements(p.scores)]]>

        <programlisting>

        <para>
            Note that these constructs - <literal>size, elements,
            <literal>indices, minindex, maxindex,
            <literal>minelement, maxelement - can only be used in
            the where clause in Hibernate3.
        </para>

        <para>
            Elements of indexed collections (arrays, lists, and maps) can be referred to by
            index in a where clause only:
        </para>

        <programlisting>

        <programlisting>

        <programlisting>

        <programlisting>

        <para>
            The expression inside <literal>[] can even be an arithmetic expression:
        </para>

        <programlisting>

        <para>
            HQL also provides the built-in <literal>index() function for elements
            of a one-to-many association or collection of values.
        </para>

        <programlisting>

        <para>
            Scalar SQL functions supported by the underlying database can be used:
        </para>

        <programlisting>

        <para>
            Consider how much longer and less readable the
            following query would be in SQL:
        </para>

        <programlisting>

        <para>
            <emphasis>Hint: something like
        </para>

        <programlisting>

    </section>

    <section id="queryhql-ordering">
        <title>The order by clause

        <para>
            The list returned by a query can be ordered by any property of a returned class or components:
        </para>

        <programlisting>

        <para>
            The optional <literal>asc or desc indicate ascending or descending order
            respectively.
        </para>
    </section>

    <section id="queryhql-grouping" revision="1">
        <title>The group by clause

        <para>
            A query that returns aggregate values can be grouped by any property of a returned class or components:
        </para>

        <programlisting>

        <programlisting>

        <para>
            A <literal>having clause is also allowed.
        </para>

        <programlisting>

        <para>
            SQL functions and aggregate functions are allowed in the <literal>having
            and <literal>order by clauses if they are supported by the underlying database
            (i.e., not in MySQL).
        </para>

        <programlisting>

        <para>
            Neither the <literal>group by clause nor the
            <literal>order by clause can contain arithmetic expressions.
            Hibernate also does not currently expand a grouped entity,
            so you cannot write <literal>group by cat if all properties
            of <literal>cat are non-aggregated. You have to list all
            non-aggregated properties explicitly.
        </para>

    </section>

    <section id="queryhql-subqueries" revision="3">
        <title>Subqueries

        <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>

        <programlisting>

        <programlisting>

        <programlisting>

        <programlisting>

        <para>
            Note that HQL subqueries can occur only in the select or where clauses.
        </para>

        <para>
            Note that subqueries can also utilize <literal>row value constructor syntax.  See
            <xref linkend="queryhql-tuple"/> for more information.
        </para>

    </section>

    <section id="queryhql-examples">
        <title>HQL examples

        <para>
            Hibernate queries can be quite powerful and complex. In fact, the power of the query language
            is one of Hibernate's main strengths. The following example queries are similar to queries
            that have been used on recent projects. Please note that most queries you will write will be much simpler than the following examples.
        </para>

        <para>
            The following query returns the order id, number of items, the given minimum total value and the total value of the order for all
            unpaid orders for a particular customer. The results are ordered by
            total value. In determining the prices, it uses the current catalog. The resulting SQL query,
            against the <literal>ORDER, ORDER_LINE, PRODUCT,
            <literal>CATALOG and PRICE tables has four inner joins and an
            (uncorrelated) subselect.
        </para>

        <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>

        <para>
            The next query counts the number of payments in each status, excluding all payments in the
            <literal>AWAITING_APPROVAL 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, PAYMENT_STATUS and
            <literal>PAYMENT_STATUS_CHANGE tables.
        </para>

        <programlisting>

        <para>
            If the <literal>statusChanges collection was mapped as a list, instead of a set,
            the query would have been much simpler to write.
        </para>

        <programlisting>

        <para>
            The next query uses the MS SQL Server <literal>isNull() 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, PAYMENT, PAYMENT_STATUS,
            <literal>ACCOUNT_TYPE, ORGANIZATION and
            <literal>ORG_USER tables.
        </para>

        <programlisting>

        <para>
            For some databases, we would need to do away with the (correlated) subselect.
        </para>

        <programlisting>

   </section>

    <section id="queryhql-bulk" revision="2">
        <title>Bulk update and delete

        <para>
            HQL now supports <literal>update, delete and
            <literal>insert ... select ... statements.
            See <xref linkend="batch-direct"/> for more information.
        </para>
    </section>

    <section id="queryhql-tipstricks">
        <title>Tips & Tricks

        <para>
            You can count the number of query results without returning them:
        </para>

        <programlisting role="JAVA">

        <para>
            To order a result by the size of a collection, use the following query:
        </para>

        <programlisting>

        <para>
            If your database supports subselects, you can place a condition upon selection
            size in the where clause of your query:
        </para>

        <programlisting>= 1]]>

        <para>
            If your database does not support subselects, use the following query:
        </para>

        <programlisting></programlisting>


        <para>
            As this solution cannot return a <literal>User with zero messages
            because of the inner join, the following form is also useful:
        </para>

        <programlisting>

        <para>
            Properties of a JavaBean can be bound to named query parameters:
        </para>

        <programlisting role="JAVA">

        <para>
            Collections are pageable by using the <literal>Query interface with a filter:
        </para>

        <programlisting role="JAVA">

        <para>
            Collection elements can be ordered or grouped using a query filter:
        </para>

        <programlisting role="JAVA">

        <para>
            You can find the size of a collection without initializing it:
        </para>

        <programlisting role="JAVA">

    </section>

    <section id="queryhql-components">
        <title>Components

        <para>
            Components can be used similarly to the simple value types that are used in HQL
            queries.  They can appear in the <literal>select clause as follows:
        </para>

        <programlisting>
        <programlisting>

        <para>
            where the Person's name property is a component.  Components can also be used
            in the <literal>where clause:
        </para>

        <programlisting>
        <programlisting>

        <para>
            Components can also be used in the <literal>order by clause:
        </para>

        <programlisting>
        <programlisting>

        <para>
            Another common use of components is in <link linkend="queryhql-tuple">row value constructors.
        </para>
    </section>

    <section id="queryhql-tuple">
        <title>Row value constructor syntax

        <para>
            HQL supports the use of ANSI SQL <literal>row value constructor syntax, sometimes
            referred to AS <literal>tuple syntax, even though the underlying database may not support
            that notion.  Here, we are generally referring to multi-valued comparisons, typically associated
            with components.  Consider an entity Person which defines a name component:
        </para>

        <programlisting>

        <para>
            That is valid syntax although it is a little verbose.  You can make this more concise by using
            <literal>row value constructor syntax:
        </para>

        <programlisting>

        <para>
            It can also be useful to specify this in the <literal>select clause:
        </para>

        <programlisting>

        <para>
            Using <literal>row value constructor syntax can also be beneficial
            when using subqueries that need to compare against multiple values:
        </para>

        <programlisting>

        <para>
            One thing to consider when deciding if you want to use this syntax, is that the query will
            be dependent upon the ordering of the component sub-properties in the metadata.
        </para>

    </section>

</chapter>