| Title: Path Expressions |
| |
| <P>Before we start discussing how to build expressions, it is important to understand one group of expressions widely used in Cayenne: <EM>path expressions</EM>. There are two types of path expressions: object path used to navigate graphs of Java objects that follow Java Bean property naming conventions and database path used to navigate the database schema. General form of path expressions is the following:</P> |
| |
| <DIV class="preformatted panel" style="border-width: 1px;"><DIV class="preformattedContent panelContent"> |
| <PRE>[db:]segment[+][.segment[+]...]</PRE> |
| </DIV></DIV> |
| |
| <UL> |
| <LI>"db:" an optional prefix indicating the the following path is a DB path.</LI> |
| <LI>"segment" - a name of a relationship or an attribute in the path. Path must have at least one segment; segments are separated by dot (".").</LI> |
| <LI>"+" - OUTER JOIN indicator: a plus sign at the end of a segment name indicates that when a JOIN is created for the path, it must be an OUTER JOIN.</LI> |
| </UL> |
| |
| |
| <H3><A name="PathExpressions-ObjectPathExpressions"></A>Object Path Expressions</H3> |
| <P>An Object Path Expression is a property navigation path. Such path is represented by a String made of dot-separated names of properties of a Java Bean class. E.g. a path expression "toArtist.artistName" is a valid property path for a Painting class, pointing to the name of the Artist who created a given Painting. A few more examples:</P> |
| |
| <UL> |
| <LI><TT>paintingTitle</TT> Can be used to navigate to the value of "paintingTitle" property of the Painting class.</LI> |
| <LI><TT>toArtist.exhibitArray.closingDate</TT> Can be used to navigate to a closing date of any of the exhibits of a Painting's Artist object.</LI> |
| <LI><TT>toArtist.exhibitArray+.closingDate</TT> Same with an OUTER JOIN on exhibits</LI> |
| </UL> |
| |
| |
| <DIV class="panelMacro"><TABLE class="infoMacro"><COLGROUP><COL width="24"><COL></COLGROUP><TR><TD valign="top"><IMG src="http://cayenne.apache.org/docs/3.0/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></TD><TD><B>What Does 'navigation' Means</B><BR>The term "navigation" in the description above could mean different things depending on the context. For instance, when evaluating an expression in memory, "navigating" an object path would simply return the value of a corresponding object property. When the same expression is used in a select query qualifier, it resolves to the name of a table column used in a WHERE clause of a generated SQL statement.</TD></TR></TABLE></DIV> |
| |
| <H3><A name="PathExpressions-DatabasePathExpressions"></A>Database Path Expressions</H3> |
| <P>Database Path Expressions provide an easy way to navigate through DB table joins. Instead of complex join semantics such expressions utilize the names of DbRelationships defined in Cayenne DataMap. Translating the above object path examples into the DB realm, database path expressions might look like this:</P> |
| |
| <UL> |
| <LI><TT>db:PAINTING_TITLE</TT> Can be used to match the value of "PAINTING_TITLE" column of a PAINTING table.</LI> |
| <LI><TT>db:toArtist.artistExhibitArray.toExhibit.CLOSING_DATE</TT> Can be used to match a closing date of any of the exhibits of a related artist record.</LI> |
| </UL> |
| |
| |
| <P>Though database path expressions are widely used by Cayenne framework internally, they are rarely used in applications. Although there are a few cases when their explicit use is justified.</P> |
| |
| <H3><A name="PathExpressions-AliasesinPathExpressions"></A>Aliases in Path Expressions</H3> |
| |
| <P>Cayenne supports "aliases" in path Expressions. E.g. the same expression can be written using explicit path or an alias:</P> |
| |
| <UL> |
| <LI>Full path: <TT>toArtist.exhibitArray.closingDate</TT></LI> |
| <LI>Using alias "e": <TT>e.closingDate</TT></LI> |
| </UL> |
| |
| |
| <P>SelectQuery using the second form of the path expression must be made aware of the alias via <TT>"SelectQuery.aliasPathSplits(..)"</TT>, otherwise an Exception will be thrown. The main use of aliases is to allow users to control how SQL joins are generated if the same path is encountered more than once in any given Expression. Each alias for any given path would result in a separate join. Without aliases, a single join will be used for a group of matching paths.</P> |
| |
| <H3><A name="PathExpressions-MatchingPathExpressions"></A>Matching Path Expressions</H3> |
| |
| <P>As described in the following chapters a path expression is usually matched against some value (see for example <A href="expression-factory-utilities.html" title="Expression Factory Utilities">ExpressionFactory API</A> - the first argument to each method is a path, and a second - an object value that is matched against the path). A type of such value must be compatible with the type of the property pointed to by the path. E.g. <TT>toArtist.artistName</TT> can only be matched against a <TT>String</TT>, and <TT>toArtist</TT> - against instances of <TT>Artist</TT>.</P> |
