[ 
https://issues.apache.org/jira/browse/DERBY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472754
 ] 

A B commented on DERBY-681:
---------------------------

Manish Khettry (JIRA) wrote:
> 
> Thanks for reviewing the patch. It will take me sometime to make
> the patch current and look at your comments. It has, after all, 
> been a while since I submitted the patch.

Thank you for willingness to continue working with the patch.

> I am curious-- is it typical for a patch to gather dust for a 
> few months before someone finds the time to look at it?

I don't think it's "typical" for this to happen, no.  But given the "fry your 
own fish" philosophy of open source development, this kind of thing does 
(unfortunately) happen on occasion.

The derby-dev mailing list receives a daily "subscription" email which lists 
issues having the "Patch Available" flag set.  The issues are sorted according 
to the date of that last update/comment; those at the bottom of the list are 
the ones that have been sitting the longest with no activity.  Ex.:

  http://thread.gmane.org/gmane.comp.apache.db.derby.devel/36563

That said, though, it's up to people in the community (users, developers, 
anyone--doesn't just have to be committers) to review patches and/or comment on 
the various issues according to their own interest/expertise.  And as you've 
seen, sometimes the result is that things slip through the cracks.

I noticed DERBY-681 at the bottom of the list last week, which is what prompted 
me to look it up--and in doing so I saw that it had been idle for two 
months(!).  So as I mentioned in my previous comment, I am willing to work with 
you on this patch so that it can now be committed.  Apologies for the awfully 
long delay...

It's definitely not a good thing to have patches sitting for so long without 
review.  While the decision as to who reviews what patches is entirely up to 
those in the community, you should feel free to "push" your patch if it's not 
getting any attention.  See "Extra Mile" advice on the wiki:

  http://wiki.apache.org/db-derby/PatchAdvice

And in particular, note the following quote:

"Post to the list at least every couple of weeks if you don't get review. Ask 
if someone is available to look at your patch and what additional information 
reviewers might need for review."

I have found that sending an explicit email to derby-dev asking for people to 
review a patch which has been idle for a couple of weeks almost always leads to 
a reply and a subsequent review.  So feel free to do so!

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

Reply via email to