[
https://issues.apache.org/jira/browse/DERBY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A B updated DERBY-681:
----------------------
Derby Info: (was: [Patch Available])
I ran derbyall with the latest patch and there was one unexpected failure
(Derby client only):
*** Start: setTransactionIsolation jdk1.4.2 DerbyNetClient derbynetmats:jdbcapi
2007-03-08 18:28:42 ***
532 del
< count=2, setTransactionIsolation() commits
532 add
> passCommitCheck=true
Test Failed.
However, I re-ran the test without your changes and it still failed, so I do
not think it's related. The machine on which I ran derbyall is one I haven't
used before so I don't know the specs; I'll look into it. In the meantime, I
went ahead and committed 681_patch3.txt with svn # 516454:
URL: http://svn.apache.org/viewvc?view=rev&rev=516454
Thank you for your patience throughout this process, Manish!
As a reminder for future patches: the more involved you are in the community as
a whole--especially in terms of reviewing other people's patches/specs--the
more likely it is that people will in turn respond to comments/patches you
yourself post, and probably in a much more timely manner. That's no guarantee,
of course (this is after all open source), but it certainly doesn't hurt ;)
In any event, thanks again for the contribution!
> Eliminate the parser's rewriting of the abstract syntax tree for queries with
> GROUP BY and/or HAVING clauses
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-681
> URL: https://issues.apache.org/jira/browse/DERBY-681
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assigned To: Manish Khettry
> Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, notes.txt
>
>
> If a query contains a GROUP BY or HAVING clause, the parser rewrites the
> abstract syntax tree, putting aggregates into a subselect and treating the
> HAVING clause as the WHERE clause of a fabricated outer select from the
> subquery. This allows the compiler to re-use some machinery since the HAVING
> clause operates on the grouped result the way that the WHERE clause operates
> on the from list. Unfortunately, this rewriting creates an explosion of
> special cases in the compiler after parsing is done. The rewriting is not
> systematically handled later on in the compiler. This gives rise to defects
> like bug 280. We need to eliminate this special rewriting and handle the
> HAVING clause in a straightforward way. This is not a small bugfix but is a
> medium sized project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
