<!-- 
RSS generated by JIRA (5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5) at Sat May 25 18:07:07 UTC 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://www.doctrine-project.org/jira/si/jira.issueviews:issue-xml/DDC-349/DDC-349.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Doctrine Project</title>
    <link>http://www.doctrine-project.org/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>5.2.7</version>
        <build-number>850</build-number>
        <build-date>21-02-2013</build-date>
    </build-info>

<item>
            <title>[DDC-349] Add support for specifying precedence in joins in DQL</title>
                <link>http://www.doctrine-project.org/jira/browse/DDC-349</link>
                <project id="10032" key="DDC">Doctrine 2 - ORM</project>
                        <description>&lt;p&gt;This request is in followup to my doctrine-user message &quot;Doctrine 2.0: Nested joins&apos;.&lt;br/&gt;
I am a bit surprised by the responses in that defining precedences in joins by placing parenthesis around join expressions is not well-known. Although not in the original SQL92 specification it is a major and important feature offered by all the RDBMS&apos;s that Doctrine 2 supports, and oftenly performs better than using subselects or alike. Doctrine 1 did not support it, but imho Doctrine 2 should support it to be a mature allround ORM.&lt;/p&gt;

&lt;p&gt;As a short example the following is a SQL statement with a nested join, where the nesting is absolutely necessary to return only a&apos;s together with either both b&apos;s and c&apos;s or no b&apos;s and c&apos;s at all:&lt;/p&gt;

&lt;p&gt;SELECT *&lt;br/&gt;
  FROM a A&lt;br/&gt;
  LEFT JOIN (&lt;br/&gt;
    b B&lt;br/&gt;
    INNER JOIN c C ON C.b_id = B.id&lt;br/&gt;
  ) ON B.a_id = A.id&lt;/p&gt;

&lt;p&gt;In order for Doctrine 2 to support this the BNF should be something like:&lt;br/&gt;
Join ::= [&quot;LEFT&quot; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;OUTER&amp;quot;&amp;#93;&lt;/span&gt; | &quot;INNER&quot;] &quot;JOIN&quot; ( &quot;(&quot; JoinAssociationPathExpression &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;AS&amp;quot;&amp;#93;&lt;/span&gt; AliasIdentificationVariable Join &quot;)&quot; | JoinAssociationPathExpression &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;AS&amp;quot;&amp;#93;&lt;/span&gt; AliasIdentificationVariable ) &lt;span class=&quot;error&quot;&gt;&amp;#91;(&amp;quot;ON&amp;quot; | &amp;quot;WITH&amp;quot;) ConditionalExpression&amp;#93;&lt;/span&gt;&lt;br/&gt;
instead of the current:&lt;br/&gt;
Join ::= [&quot;LEFT&quot; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;OUTER&amp;quot;&amp;#93;&lt;/span&gt; | &quot;INNER&quot;] &quot;JOIN&quot; JoinAssociationPathExpression &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;quot;AS&amp;quot;&amp;#93;&lt;/span&gt; AliasIdentificationVariable &lt;span class=&quot;error&quot;&gt;&amp;#91;(&amp;quot;ON&amp;quot; | &amp;quot;WITH&amp;quot;) ConditionalExpression&amp;#93;&lt;/span&gt; &lt;/p&gt;

&lt;p&gt;This would allow DQL like:&lt;/p&gt;

&lt;p&gt;SELECT A, B, C&lt;br/&gt;
  FROM a A&lt;br/&gt;
  LEFT JOIN (&lt;br/&gt;
    A.b B&lt;br/&gt;
    INNER JOIN B.c C&lt;br/&gt;
  ) WITH B.something = &apos;value&apos; AND C.something = &apos;othervalue&apos;&lt;/p&gt;

&lt;p&gt;What further needs to be done is that the DQL parser loosly couples the ConditionalExpression to any of the previously parsed JoinAssociationPathExpression&apos;s instead of tieing it explicitely to the JoinAssociationPathExpression that preceedes it according to the old BNF notation. The new BNF should however not require any changes to the hydrator. Therefore I have the feeling that improving the DQL parser for nested joins does not require extensive work, while the benefit of running these kind of queries is considerable.&lt;/p&gt;

&lt;p&gt;As an extra substantiation here are links to (BNF) FROM clause documentations of the RDBMS&apos;s that Doctrine 2 supports, they all show support for nested joins:&lt;br/&gt;
MySQL: &lt;a href=&quot;http://dev.mysql.com/doc/refman/5.0/en/join.html&quot; class=&quot;external-link&quot;&gt;http://dev.mysql.com/doc/refman/5.0/en/join.html&lt;/a&gt;&lt;br/&gt;
PostgreSQL: &lt;a href=&quot;http://www.postgresql.org/docs/8.4/interactive/sql-select.html#SQL-FROM&quot; class=&quot;external-link&quot;&gt;http://www.postgresql.org/docs/8.4/interactive/sql-select.html#SQL-FROM&lt;/a&gt; and &lt;a href=&quot;http://www.postgresql.org/docs/8.1/interactive/explicit-joins.html&quot; class=&quot;external-link&quot;&gt;http://www.postgresql.org/docs/8.1/interactive/explicit-joins.html&lt;/a&gt;&lt;br/&gt;
MSSQL: &lt;a href=&quot;http://msdn.microsoft.com/en-us/library/ms177634.aspx&quot; class=&quot;external-link&quot;&gt;http://msdn.microsoft.com/en-us/library/ms177634.aspx&lt;/a&gt;&lt;br/&gt;
Oracle: &lt;a href=&quot;http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_10002.htm#CHDDCHGF&quot; class=&quot;external-link&quot;&gt;http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_10002.htm#CHDDCHGF&lt;/a&gt;&lt;br/&gt;
SQLite: &lt;a href=&quot;http://www.sqlite.org/syntaxdiagrams.html#single-source&quot; class=&quot;external-link&quot;&gt;http://www.sqlite.org/syntaxdiagrams.html#single-source&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;I surely hope you will consider implementing this improvement because it would save me and others from the hassle of writing raw SQL queries or executing multiple (thus slow) queries in DQL for doing the same. Thanks anyway for the great product so far!&lt;/p&gt;</description>
                <environment></environment>
            <key id="10915">DDC-349</key>
            <summary>Add support for specifying precedence in joins in DQL</summary>
                <type id="4" iconUrl="http://www.doctrine-project.org/jira/images/icons/issuetypes/improvement.png">Improvement</type>
                                <priority id="3" iconUrl="http://www.doctrine-project.org/jira/images/icons/priorities/major.png">Major</priority>
                    <status id="1" iconUrl="http://www.doctrine-project.org/jira/images/icons/statuses/open.png">Open</status>
                    <resolution id="-1">Unresolved</resolution>
                    <security id="10000">All</security>
                        <assignee username="romanb">Roman S. Borschel</assignee>
                                <reporter username="dennis.verspuij">Dennis Verspuij</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Feb 2010 09:52:45 +0000</created>
                <updated>Wed, 1 May 2013 18:46:53 +0000</updated>
                                    <version>2.0-ALPHA4</version>
                                                <component>DQL</component>
                        <due></due>
                    <votes>1</votes>
                        <watches>1</watches>
                        <comments>
                    <comment id="12650" author="guilhermeblanco" created="Tue, 13 Apr 2010 00:04:10 +0000"  >&lt;p&gt;This seems to be a valid issue to me.&lt;/p&gt;

&lt;p&gt;This implementation is the actual solution to associations retrieval that are inherited (type joined).&lt;/p&gt;

&lt;p&gt;Example:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;/** Joined */
class Base {}

class Foo &lt;span class=&quot;code-keyword&quot;&gt;extends&lt;/span&gt; Base {}

class Bar {
    &lt;span class=&quot;code-keyword&quot;&gt;public&lt;/span&gt; $foo;
}

&lt;span class=&quot;code-comment&quot;&gt;// This causes the CTI to link as INNER JOIN, which makes the result become 0
&lt;/span&gt;&lt;span class=&quot;code-comment&quot;&gt;// il &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; you have no Foo&apos;s defined (although it should ignore &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;)
&lt;/span&gt;$q = $&lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt;-&amp;gt;_em-&amp;gt;createQuery(&apos;SELECT b, f FROM Bar b LEFT JOIN b.foo f&apos;); 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                    <comment id="12654" author="romanb" created="Tue, 13 Apr 2010 04:40:05 +0000"  >&lt;p&gt;Yes, this is a possible solution for &lt;a href=&quot;http://www.doctrine-project.org/jira/browse/DDC-512&quot; title=&quot;LEFT JOIN of extended null entity cause empty result [testcase included]&quot;&gt;&lt;del&gt;DDC-512&lt;/del&gt;&lt;/a&gt; but on the &lt;b&gt;SQL level&lt;/b&gt;. I still don&apos;t see this as appropriate for DQL, it just doesnt make sense to me, DQL joins object associations, there is no precedence.&lt;/p&gt;</comment>
                    <comment id="12656" author="romanb" created="Tue, 13 Apr 2010 05:46:00 +0000"  >&lt;p&gt;So, no, this has nothing to do with &lt;a href=&quot;http://www.doctrine-project.org/jira/browse/DDC-512&quot; title=&quot;LEFT JOIN of extended null entity cause empty result [testcase included]&quot;&gt;&lt;del&gt;DDC-512&lt;/del&gt;&lt;/a&gt;. &lt;a href=&quot;http://www.doctrine-project.org/jira/browse/DDC-512&quot; title=&quot;LEFT JOIN of extended null entity cause empty result [testcase included]&quot;&gt;&lt;del&gt;DDC-512&lt;/del&gt;&lt;/a&gt; can even be fixed differently as outlined in my comments there.&lt;/p&gt;</comment>
                    <comment id="12657" author="romanb" created="Tue, 13 Apr 2010 05:52:20 +0000"  >&lt;p&gt;On a side note I would still like to know/see the following for this issue:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;Some realisitic DQL examples where this feature would be essential, i.e. there is no other way to do it.&lt;br/&gt;
   This also means explaining what the impact on the resulting object graph is and why it makes sense.&lt;/li&gt;
	&lt;li&gt;Which other ORMs support this on the OQL/Criteria level?&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;So far, my stance on this issue is:&lt;/p&gt;

&lt;p&gt; 1) It doesnt make sense (semantically) in DQL&lt;br/&gt;
 2) Its rarely needed&lt;br/&gt;
 3) When you really need it you can use a NativeQuery anyway and use this nesting in SQL, where it probably belongs and makes more sense&lt;br/&gt;
 4) It would (unnecessarily) complicate DQL&lt;/p&gt;

&lt;p&gt;Thus I am currently leaning towards &quot;Wont fix&quot; for this issue.&lt;/p&gt;</comment>
                    <comment id="12662" author="dennis.verspuij" created="Tue, 13 Apr 2010 13:53:13 +0000"  >&lt;p&gt;Hi Roman. I understand your doubts, and I have been breaking my head over&lt;br/&gt;
creating a realistic example the last few hours that would hopefully convince&lt;br/&gt;
you for implementing this feature. But actually I cannot find one that you wouldn&apos;t&lt;br/&gt;
consider to be trivial. I do have a number of very complex optimized queries written&lt;br/&gt;
for sportskickoff dot com (using Doctrine 1.2) but they are probably hard to understand&lt;br/&gt;
because they may not be selfdescribing. Below is one example literally ripped from&lt;br/&gt;
the application. Still they often can be broken down to my example query in this&lt;br/&gt;
ticket&apos;s description, but applied grouping, additional other joins on the root component&lt;br/&gt;
and/or other criteria made them impossible to rewrite using subselects or choosing&lt;br/&gt;
another root component. Most often they just performed way best using the nested&lt;br/&gt;
syntax and saved me a number of additional queries.&lt;/p&gt;

&lt;p&gt;SELECT A.id, A.username, A.balance, COALESCE(SUM(B.stake), 0) AS sumstake, COUNT(B.id) AS nrbets&lt;br/&gt;
FROM account A&lt;br/&gt;
LEFT JOIN (&lt;br/&gt;
  bet B&lt;br/&gt;
  INNER JOIN game G ON G.id = :GAMEID AND B.timestampcompletion BETWEEN G.timestampstart AND G.timestampend&lt;br/&gt;
) ON B.accountid = A.id AND B.timestampcompletion IS NOT NULL&lt;br/&gt;
WHERE A.Status &amp;amp; :ACTIVEORDISQUALIFIED = :ACTIVE&lt;br/&gt;
GROUP BY A.id, A.username, A.balance&lt;br/&gt;
ORDER BY A.balance DESC, sumstake ASC, nrbets ASC, A.username ASC&lt;/p&gt;

&lt;p&gt;But let&apos;s put it another way. I would also like this feature to be supported in DQL&lt;br/&gt;
because I just do not want to use native queries. Why would I want to use native&lt;br/&gt;
queries if it can be done using DQL? In DQL I work with class names and field&lt;br/&gt;
names, and they may differ from the underlying table and column names. Doctrine&lt;br/&gt;
takes care of that mapping based on my schema/annotations and I do not&lt;br/&gt;
have to &quot;know&quot; these mappings. In native queries I suddenly do have to &quot;know&quot;&lt;br/&gt;
these mappings. I use Doctrine because it makes my application portable and&lt;br/&gt;
enables me to work with my database in an OOP way like I do in my model,&lt;br/&gt;
abstracting things. The need for native queries partly reverts the benefits Doctrine&lt;br/&gt;
offers in the first place.&lt;/p&gt;

&lt;p&gt;Btw, I recall to have successfully used the nested join syntax in HQL (.NET Hibernate)&lt;br/&gt;
but I cannot find examples on the web or a BNF notation.&lt;/p&gt;

&lt;p&gt;Furthermore, in reply to your stances:&lt;br/&gt;
1) It indeed doesnt make sense (semantically) in DQL, it only makes the result&lt;br/&gt;
  set different, but not the way data is hydrated into objects;&lt;br/&gt;
2) Its indeed rarely needed for inserting, updating and populating basic lists but&lt;br/&gt;
  it allows you to better select what combinations of associated rows are joined&lt;br/&gt;
  and which not in more optimized queries without having to use native queries,&lt;br/&gt;
  or because they perform better than using subseletcs and alike.&lt;br/&gt;
3) Not having to use native queries is just an extra reason for using Doctrine and&lt;br/&gt;
  maintains the abstraction the ORM provides througout on&apos;es whole application&lt;br/&gt;
4) Why would it complicate DQL, if people do not know about or understand&lt;br/&gt;
  the feature it wouldn&apos;t matter because not using parenthesises is the default&lt;br/&gt;
  way to specify joins?&lt;/p&gt;

&lt;p&gt;Well, this is it, can&apos;t find any more words to promote and make you enthusiastic.... lol.&lt;/p&gt;</comment>
                    <comment id="12663" author="dennis.verspuij" created="Tue, 13 Apr 2010 17:48:39 +0000"  >&lt;p&gt;Ok, I have not given up yet... &lt;img class=&quot;emoticon&quot; src=&quot;http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif&quot; height=&quot;20&quot; width=&quot;20&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;, here&apos;s a &quot;stupid&quot; example.&lt;/p&gt;

&lt;p&gt;Imagine a book store that sells books of various authors and keeps track of those sales.&lt;br/&gt;
Let&apos;s say you would have an admin page that lists all authors, and for each author&lt;br/&gt;
its also shows the books and their sales dates since january 1st, but only for those&lt;br/&gt;
books that were actually sold and contain an A in its name. An optimized SQL query&lt;br/&gt;
to fetch all the information at once would be something like:&lt;/p&gt;

&lt;p&gt;SELECT A.&lt;b&gt;, B.&lt;/b&gt;, S.*&lt;br/&gt;
  FROM author A&lt;br/&gt;
  LEFT JOIN (&lt;br/&gt;
    book B&lt;br/&gt;
    INNER JOIN sale S ON S.book_id = B.id AND S.dt &amp;gt;= &apos;2010-01-01&apos;&lt;br/&gt;
  ) ON B.author_id = A.id AND A.name LIKE &apos;%A%&apos;&lt;/p&gt;

&lt;p&gt;In DQL it would then be something like:&lt;/p&gt;

&lt;p&gt;SELECT A.&lt;b&gt;, B.&lt;/b&gt;, S.*&lt;br/&gt;
  FROM author A&lt;br/&gt;
  LEFT JOIN (&lt;br/&gt;
    book B&lt;br/&gt;
    INNER JOIN sale S WITH S.dt &amp;gt;= &apos;2010-01-01&apos;&lt;br/&gt;
  ) WITH A.name LIKE &apos;%A%&apos;&lt;/p&gt;

&lt;p&gt;If the database would contain thousands of books, but sales for just a&lt;br/&gt;
few books, this will definitely perform better than using subselects.&lt;br/&gt;
Off course one would like to fetch array graphs instead of objects for&lt;br/&gt;
further optimization, but this hopefully shows my point.&lt;/p&gt;

&lt;p&gt;I have attached a test casefor a similar query, though without the additional&lt;br/&gt;
join constraints for clarity. I surely hope you can consider it.&lt;/p&gt;

&lt;p&gt;One last note, you shouldn&apos;t be afraid that nesting joins is not in the&lt;br/&gt;
ansi SQL spec. Select queries are about record sets and products&lt;br/&gt;
between these sets, tables are just the basic means of providing record&lt;br/&gt;
sets to the query. This is an important terminological difference to think about.&lt;br/&gt;
Specifying precedence with parenthesis around joins is a logical and&lt;br/&gt;
natural evolution of the ansi sql standard. For example views are a good&lt;br/&gt;
proof of this concept, I could define book B INNER JOIN sale S as a view&lt;br/&gt;
and LEFT JOIN that to authors to get effectively the same result&lt;br/&gt;
set as the above example. The database server would internally perform the&lt;br/&gt;
same query (though may additionally take indexes on the view into account).&lt;br/&gt;
That said, rdbm&apos;s that support this syntax would certainly never drop the&lt;br/&gt;
feature, as its not a feature but just plain logical and smart querying!&lt;/p&gt;

&lt;p&gt;P.S. I had a hard time finding out how to run the test cases, I could not find&lt;br/&gt;
it in the Doctrine 2 documentation, development wiki, cookbook or any other&lt;br/&gt;
place, while finally it was as easy as running phpunit  Doctrine_Tests_AllTests&lt;br/&gt;
from within the tests/ directory, or just phpunit  Doctrine_Tests_ORM_Functional_Ticket_DDC349Test&lt;br/&gt;
for my test. Could you please add some info about this somewhere, it might&lt;br/&gt;
save others some googling.&lt;/p&gt;</comment>
                    <comment id="12664" author="dennis.verspuij" created="Tue, 13 Apr 2010 17:50:11 +0000"  >&lt;p&gt;Test case as SVN patch using a parenthesized join.&lt;br/&gt;
Just remove the parenthesises from the query to have it fail...&lt;/p&gt;</comment>
                    <comment id="13083" author="romanb" created="Sat, 29 May 2010 06:37:17 +0000"  >&lt;p&gt;@&quot;The need for native queries partly reverts the benefits Doctrine offers in the first place.&quot;&lt;/p&gt;

&lt;p&gt;That is something I hugely disagree with. Neither SQL abstraction, nor database vendor independence is the main purpose of an ORM like Doctrine 2.&lt;br/&gt;
It is the &lt;b&gt;state management of your objects, the transparent change tracking, lazy-loading and synchronization of the object state with the database state&lt;/b&gt; and nothing of this gets lost when using native queries.&lt;/p&gt;

&lt;p&gt;We could rip out DQL and any other querying mechanism except a basic find() (and lazy-loading, of course), only providing the native query facility and even only supporting MySQL and would still retain all the core ORM functionality.&lt;/p&gt;

&lt;p&gt;NativeQuery is one of the best and core &quot;features&quot; of the project. It is even the &lt;b&gt;foundation&lt;/b&gt; for DQL. A DQL query is nothing more than an additional (beautiful) abstraction but what comes out is a native query + a ResultSetMapping, the same thing you can build yourself in the first place, &lt;b&gt;even using the mapping metadata to construct the query&lt;/b&gt;. Nothing forces you to hardcode table and column names in native queries if you don&apos;t want that. Just use the mapping metadata, DQL does the same.&lt;/p&gt;

&lt;p&gt;SQL abstraction and database vendor independence is icing on the cake, not the heart of the ORM.&lt;/p&gt;</comment>
                </comments>
                <issuelinks>
                        <issuelinktype id="10000">
                <name>Duplicate</name>
                                                <inwardlinks description="is duplicated by">
                            <issuelink>
            <issuekey id="12797">DDC-1256</issuekey>
        </issuelink>
                    </inwardlinks>
                            </issuelinktype>
                    </issuelinks>
                <attachments>
                    <attachment id="10569" name="DDC349Test.patch" size="5354" author="dennis.verspuij" created="Tue, 13 Apr 2010 17:50:11 +0000" />
                </attachments>
            <subtasks>
        </subtasks>
        </item>
</channel>
</rss>