You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by TomohitoNakayama <to...@basil.ocn.ne.jp> on 2005/02/09 08:35:37 UTC
About improvement of DERBY-134
Hello.
My name is Naka.
I'm very newbie in derby community.
I'm now seeing report for derby in ASF Jira.
And found a interesting issue.
That's
"DERBY-124 Sorted string columns are sorted in a case sensitive way"
This issue seems to mean that we can't use complex item in order clause.
#That title was difficult to understand a bit ....
Solving this isn't useful?
Especially when we manipulate DBMS by hand.
What I think we need to do is as next:
1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj".
2) Make OrderByColumn class to support additiveExpression.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> I am still new to Apache processes. According to the following DB project
> guidelines, "All contributors should have a Contributor License Agreement
> <http://www.apache.org/licenses/#clas>on file." I know bug patches are exempt
> from this requirement.
>
> http://db.apache.org/source.html
>
Having a CLA on file does clear things up but we don't want everyone to
be forecd to have a lawyer review some agreement before contributing.
There's no real distinction between posting a patch for a bug fix or
posting a patch that is an enhancement or improvement.
Now if the patch is a large body of work (by some definition of large)
then we may well ask for a CLA, confirmation from the contributor's
employer that they approve of the contribution, and possibly a software
grant from them as well if it was something they may have title to. The
premis is
1) if they did the work for a company we need to know that the company
wants it contributed (sw grant and CCLA required)
2) if they did the work independently that their employer is aware
Finally, if someone does do a large body of work then there's a real
good chance that they will become a committer at which point a CLA will
be required anyway.
--
Jeremy
Re: About improvement of DERBY-134
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Satheesh Bandaram wrote:
> I am still new to Apache processes. According to the following DB
> project guidelines, "All contributors should have a Contributor License
> Agreement <http://www.apache.org/licenses/#clas>on file." I know bug
> patches are exempt from this requirement.
and it's not just the DB project, from http://www.apache.org/licenses/#clas
"The ASF desires that all contributors of ideas, code, or documentation
to the Apache projects complete, sign, and submit (via snailmail or fax)
a Individual Contributor License Agreement (CLA)"
So it's not "need" or "require", but "should" and "desire". Thus there
should be no problem in asking any contributor to sign a CLA. If they do
not, then, I guess we would have to look carefully at the contribution
to decide if it can be accepted without a CLA.
Dan.
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> Since you are working on an enhancement to Derby, you need to sign a CLA with
> Apache.
>
A CLA is usually only required when someone becomes a committer. There
is a flag in Jira which indicates whether code attached to issues is
licensed to the ASF; patches submitted to the list are public contributions.
--
Jeremy
Re: [Patch] Re: About improvement of DERBY-134
Posted by Mamta Satoor <ms...@gmail.com>.
On Tue, 29 Mar 2005 20:44:30 +0900, TomohitoNakayama
<to...@basil.ocn.ne.jp> wrote:
> Waiting 1 day and no error was found.
> Can I ask committers to commit this patch ?
>
> Or I should commit it by myself ?
Hi Tomohito,
Great job with being so persistent with this bug.
As for commiting the patch, one of the Derby committers will need to
commit it for you.
Mamta
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by Kathey Marsden <km...@sbcglobal.net>.
Danesh Irani wrote:
>Hello Kathey,
>
>Christian when reporting Derby-167 had a few possible solutions, is
>Satheesh's proposed SQL Standard way included in one of those? If not
>could you perhaps elaborate a little on what Satheesh proposed.
>Personally I think all 3 of Christians solutions would add value in
>terms of flexibility to Derby.
>
>Thanks
>~Danesh
>
>
>
I couldn't find Satheesh's mail but yes it was regarding option 1,
generated by default. I looked up the SQL syntax in the sql standard
and put a comment in the JIRA entry.
Kathey
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by Danesh Irani <da...@gmail.com>.
Hello Kathey,
Christian when reporting Derby-167 had a few possible solutions, is
Satheesh's proposed SQL Standard way included in one of those? If not
could you perhaps elaborate a little on what Satheesh proposed.
Personally I think all 3 of Christians solutions would add value in
terms of flexibility to Derby.
Thanks
~Danesh
On Apr 2, 2005 10:39 AM, Kathey Marsden <km...@sbcglobal.net> wrote:
> TomohitoNakayama wrote:
>
> > Hello.
> >
> > Thank for all who advise and help me !
> >
> > Now I'm reading code of derby here and there , and found this program
> > is very attractive.
> > I want to find next material for hacking :D
> >
>
> Hello Tomohito,
>
> Since you are looking for a next project , I wanted to put a plug in
> for my personal crusade for
>
> Derby-167. Inserting values in an identity column.
> http://issues.apache.org/jira/browse/DERBY-167
>
> I think would be tremendous value you in implementing this feature as
> currently it is not possible to import data to Derby if you have an
> autoincrement column and want to keep your primary keys intact. I know
> there are others who have expressed interest and would be willing to
> help you in this project. I don't want to get into too many details
> on this thread outside the Jira comments but just to give you an idea,
> Satheesh I think proposed a specific SQL Standard way to do this and
> Mamta promised support with reviews or whatever.
>
> I'd suggest first submit a proposed solution to the community and get
> consensus before starting to implement a solution.
> I think it would be a way for you to add huge value to Derby.
>
> Thanks
>
> Kathey
>
>
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
>> 2:being able to disable the "identity" feature for a column
>> 3:being able to generate a column as non identity and after data is
>> populated, alter table to add the "identity" to the column
I think those are needed to allow user to enable loading data "AND" keep
values at identity column tidy.
(Now "tidy" means user can't decide pk value at their discretion.)
We should have both approaches after all ...
Then I think this is matter of priority.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden" <km...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Sunday, April 03, 2005 11:12 PM
Subject: Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I was interested in issue of Derby-167...
>>
>> I recognized there was proposed three options.
>> 1:being able to "generate by default as identity"
>> 2:being able to disable the "identity" feature for a column
>> 3:being able to generate a column as non identity and after data is
>> populated, alter table to add the "identity" to the column
>>
>> In my opinion , option 2 and option 3 increase statuses which table
>> can take , identity feature working state and not working state,
>> so they would make it complex to maintain db.
>> On the other hand, if we take option 1, we need to prevent it from to
>> have same value in identity column.
>>
> I think it's ok to let the user prevent duplicates with a primary key
> if they want to.
> When creating the table, the user would need to make sure that they
> used START WITH to ensure that generation starts with the maximum value
> + 1. I put a comment in the bug with how I think the process would go.
>
> A bit precarious I know if you forget to create your table properly, but
> at least it makes it *possible* to load data.
> Later we could enhance support for ALTER TABLE to alter the identity
> column specification to specify a RESTART WITH value.
>
> Thanks
>
>
> Kathey
>
>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 2005/04/01
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.2 - Release Date: 2005/04/05
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I was interested in issue of Derby-167...
>
> I recognized there was proposed three options.
> 1:being able to "generate by default as identity"
> 2:being able to disable the "identity" feature for a column
> 3:being able to generate a column as non identity and after data is
> populated, alter table to add the "identity" to the column
>
> In my opinion , option 2 and option 3 increase statuses which table
> can take , identity feature working state and not working state,
> so they would make it complex to maintain db.
> On the other hand, if we take option 1, we need to prevent it from to
> have same value in identity column.
>
I think it's ok to let the user prevent duplicates with a primary key
if they want to.
When creating the table, the user would need to make sure that they
used START WITH to ensure that generation starts with the maximum value
+ 1. I put a comment in the bug with how I think the process would go.
A bit precarious I know if you forget to create your table properly, but
at least it makes it *possible* to load data.
Later we could enhance support for ALTER TABLE to alter the identity
column specification to specify a RESTART WITH value.
Thanks
Kathey
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I was interested in issue of Derby-167...
I recognized there was proposed three options.
1:being able to "generate by default as identity"
2:being able to disable the "identity" feature for a column
3:being able to generate a column as non identity and after data is
populated, alter table to add the "identity" to the column
In my opinion , option 2 and option 3 increase statuses which table can
take , identity feature working state and not working state,
so they would make it complex to maintain db.
On the other hand, if we take option 1, we need to prevent it from to have
same value in identity column.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden" <km...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Sunday, April 03, 2005 12:39 AM
Subject: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> Thank for all who advise and help me !
>>
>> Now I'm reading code of derby here and there , and found this program
>> is very attractive.
>> I want to find next material for hacking :D
>>
>
> Hello Tomohito,
>
> Since you are looking for a next project , I wanted to put a plug in
> for my personal crusade for
>
> Derby-167. Inserting values in an identity column.
> http://issues.apache.org/jira/browse/DERBY-167
>
> I think would be tremendous value you in implementing this feature as
> currently it is not possible to import data to Derby if you have an
> autoincrement column and want to keep your primary keys intact. I know
> there are others who have expressed interest and would be willing to
> help you in this project. I don't want to get into too many details
> on this thread outside the Jira comments but just to give you an idea,
> Satheesh I think proposed a specific SQL Standard way to do this and
> Mamta promised support with reviews or whatever.
>
> I'd suggest first submit a proposed solution to the community and get
> consensus before starting to implement a solution.
> I think it would be a way for you to add huge value to Derby.
>
>
> Thanks
>
> Kathey
>
>
>
>
>
>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 2005/03/30
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 2005/04/01
(Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Posted by Kathey Marsden <km...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> Thank for all who advise and help me !
>
> Now I'm reading code of derby here and there , and found this program
> is very attractive.
> I want to find next material for hacking :D
>
Hello Tomohito,
Since you are looking for a next project , I wanted to put a plug in
for my personal crusade for
Derby-167. Inserting values in an identity column.
http://issues.apache.org/jira/browse/DERBY-167
I think would be tremendous value you in implementing this feature as
currently it is not possible to import data to Derby if you have an
autoincrement column and want to keep your primary keys intact. I know
there are others who have expressed interest and would be willing to
help you in this project. I don't want to get into too many details
on this thread outside the Jira comments but just to give you an idea,
Satheesh I think proposed a specific SQL Standard way to do this and
Mamta promised support with reviews or whatever.
I'd suggest first submit a proposed solution to the community and get
consensus before starting to implement a solution.
I think it would be a way for you to add huge value to Derby.
Thanks
Kathey
Re: [Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thank for all who advise and help me !
Now I'm reading code of derby here and there , and found this program is
very attractive.
I want to find next material for hacking :D
Best regards.
PS.
I sended mail of ICLA last Thu.
If no problem happened, It will arrive.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Satheesh Bandaram" <sa...@Sourcery.Org>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, April 02, 2005 9:19 AM
Subject: Re: [Patch] Re: About improvement of DERBY-134
> Submitted this patch. Thanks for patiently addressing all concerns.
> Final patch looks really good. Hope you will continue working on
> enhancing Derby. If you would like some ideas on what to tackle next, I
> can help... :-)
>
> I think this improvement has been asked by several others in the
> community.
>
> Satheesh
>
> Sending
> java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java
> Sending
> java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java
> Sending
> java\engine\org\apache\derby\impl\sql\compile\TableName.java
> Sending java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
> Sending
> java\testing\org\apache\derbyTesting\functionTests\master\orderby.out
> Sending
> java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql
> Transmitting file data ......
> Committed revision 159746.
>
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> Thanks.
>> I see. I re-sended patch via JIRA.
>>
>> I will send ICLA in days.
>> Because it is a bit substantial , I need time ...
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Satheesh Bandaram"
>> <sa...@Sourcery.Org>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Wednesday, March 30, 2005 3:43 AM
>> Subject: Re: [Patch] Re: About improvement of DERBY-134
>>
>>
>>> I will work on committing this patch. Since you are working on an
>>> improvement, would you mind submitting this patch through Jira? Use
>>> AttachFile option and you also need to select "Grant ASF license to
>>> include in ASF works" option. (URL:
>>> http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
>>> This would help committers in accepting the patch.
>>>
>>> Also, you might want to consider signing ICLA with Apache.
>>> (http://www.apache.org/licenses/icla.txt) This will help process your
>>> contributions faster. This is also a requirement to becoming a committer
>>> at a future time.
>>>
>>> Satheesh
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> Waiting 1 day and no error was found.
>>>> Can I ask committers to commit this patch ?
>>>>
>>>> Or I should commit it by myself ?
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Tuesday, March 29, 2005 4:31 AM
>>>> Subject: Re: [Patch] Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> I have added some test to orderby.sql (and correspond result to
>>>>>> orderby.out) ,
>>>>>> which was suggested by Jack Klebanoff.
>>>>>>
>>>>>> And I have executed derbylang test and coulud not found error exept
>>>>>> for lang/floattypes.sql.
>>>>>> I think this error is not caused by my patch.
>>>>>>
>>>>>> derbylang_report.txt is attached to this mail.
>>>>>>
>>>>>> Please check this patch from a point of other person's view.
>>>>>>
>>>>>> best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>
>>>>>
>>>>>
>>>>> The latest patch looks good to me. I looked at the changes, applied
>>>>> the patch to recently updated Derby source, and successfully ran the
>>>>> derbylang test suite. (I did not even see the failure in
>>>>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>>>>> updates I picked up today).
>>>>>
>>>>> Jack Klebanoff
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Anti-Virus.
>>>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>>
>>>
>>
>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 2005/03/30
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 2005/03/30
Re: [Patch] Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Submitted this patch. Thanks for patiently addressing all concerns.
Final patch looks really good. Hope you will continue working on
enhancing Derby. If you would like some ideas on what to tackle next, I
can help... :-)
I think this improvement has been asked by several others in the community.
Satheesh
Sending
java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java
Sending
java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java
Sending java\engine\org\apache\derby\impl\sql\compile\TableName.java
Sending java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
Sending
java\testing\org\apache\derbyTesting\functionTests\master\orderby.out
Sending
java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql
Transmitting file data ......
Committed revision 159746.
TomohitoNakayama wrote:
> Hello.
>
> Thanks.
> I see. I re-sended patch via JIRA.
>
> I will send ICLA in days.
> Because it is a bit substantial , I need time ...
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Satheesh Bandaram"
> <sa...@Sourcery.Org>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, March 30, 2005 3:43 AM
> Subject: Re: [Patch] Re: About improvement of DERBY-134
>
>
>> I will work on committing this patch. Since you are working on an
>> improvement, would you mind submitting this patch through Jira? Use
>> AttachFile option and you also need to select "Grant ASF license to
>> include in ASF works" option. (URL:
>> http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
>> This would help committers in accepting the patch.
>>
>> Also, you might want to consider signing ICLA with Apache.
>> (http://www.apache.org/licenses/icla.txt) This will help process your
>> contributions faster. This is also a requirement to becoming a committer
>> at a future time.
>>
>> Satheesh
>>
>> TomohitoNakayama wrote:
>>
>>> Waiting 1 day and no error was found.
>>> Can I ask committers to commit this patch ?
>>>
>>> Or I should commit it by myself ?
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Tuesday, March 29, 2005 4:31 AM
>>> Subject: Re: [Patch] Re: About improvement of DERBY-134
>>>
>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I have added some test to orderby.sql (and correspond result to
>>>>> orderby.out) ,
>>>>> which was suggested by Jack Klebanoff.
>>>>>
>>>>> And I have executed derbylang test and coulud not found error exept
>>>>> for lang/floattypes.sql.
>>>>> I think this error is not caused by my patch.
>>>>>
>>>>> derbylang_report.txt is attached to this mail.
>>>>>
>>>>> Please check this patch from a point of other person's view.
>>>>>
>>>>> best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>
>>>>
>>>>
>>>> The latest patch looks good to me. I looked at the changes, applied
>>>> the patch to recently updated Derby source, and successfully ran the
>>>> derbylang test suite. (I did not even see the failure in
>>>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>>>> updates I picked up today).
>>>>
>>>> Jack Klebanoff
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>
>>
>
>
Re: [Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thanks.
I see. I re-sended patch via JIRA.
I will send ICLA in days.
Because it is a bit substantial , I need time ...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Satheesh Bandaram" <sa...@Sourcery.Org>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, March 30, 2005 3:43 AM
Subject: Re: [Patch] Re: About improvement of DERBY-134
>I will work on committing this patch. Since you are working on an
> improvement, would you mind submitting this patch through Jira? Use
> AttachFile option and you also need to select "Grant ASF license to
> include in ASF works" option. (URL:
> http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
> This would help committers in accepting the patch.
>
> Also, you might want to consider signing ICLA with Apache.
> (http://www.apache.org/licenses/icla.txt) This will help process your
> contributions faster. This is also a requirement to becoming a committer
> at a future time.
>
> Satheesh
>
> TomohitoNakayama wrote:
>
>> Waiting 1 day and no error was found.
>> Can I ask committers to commit this patch ?
>>
>> Or I should commit it by myself ?
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Tuesday, March 29, 2005 4:31 AM
>> Subject: Re: [Patch] Re: About improvement of DERBY-134
>>
>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> I have added some test to orderby.sql (and correspond result to
>>>> orderby.out) ,
>>>> which was suggested by Jack Klebanoff.
>>>>
>>>> And I have executed derbylang test and coulud not found error exept
>>>> for lang/floattypes.sql.
>>>> I think this error is not caused by my patch.
>>>>
>>>> derbylang_report.txt is attached to this mail.
>>>>
>>>> Please check this patch from a point of other person's view.
>>>>
>>>> best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>
>>>
>>> The latest patch looks good to me. I looked at the changes, applied
>>> the patch to recently updated Derby source, and successfully ran the
>>> derbylang test suite. (I did not even see the failure in
>>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>>> updates I picked up today).
>>>
>>> Jack Klebanoff
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>>
>>>
>>
>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 2005/03/30
Re: [Patch] Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I will work on committing this patch. Since you are working on an
improvement, would you mind submitting this patch through Jira? Use
AttachFile option and you also need to select "Grant ASF license to
include in ASF works" option. (URL:
http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
This would help committers in accepting the patch.
Also, you might want to consider signing ICLA with Apache.
(http://www.apache.org/licenses/icla.txt) This will help process your
contributions faster. This is also a requirement to becoming a committer
at a future time.
Satheesh
TomohitoNakayama wrote:
> Waiting 1 day and no error was found.
> Can I ask committers to commit this patch ?
>
> Or I should commit it by myself ?
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Jack Klebanoff"
> <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Tuesday, March 29, 2005 4:31 AM
> Subject: Re: [Patch] Re: About improvement of DERBY-134
>
>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I have added some test to orderby.sql (and correspond result to
>>> orderby.out) ,
>>> which was suggested by Jack Klebanoff.
>>>
>>> And I have executed derbylang test and coulud not found error exept
>>> for lang/floattypes.sql.
>>> I think this error is not caused by my patch.
>>>
>>> derbylang_report.txt is attached to this mail.
>>>
>>> Please check this patch from a point of other person's view.
>>>
>>> best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>
>>
>> The latest patch looks good to me. I looked at the changes, applied
>> the patch to recently updated Derby source, and successfully ran the
>> derbylang test suite. (I did not even see the failure in
>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>> updates I picked up today).
>>
>> Jack Klebanoff
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>
>>
>
>
Re: [Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Waiting 1 day and no error was found.
Can I ask committers to commit this patch ?
Or I should commit it by myself ?
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, March 29, 2005 4:31 AM
Subject: Re: [Patch] Re: About improvement of DERBY-134
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I have added some test to orderby.sql (and correspond result to
>> orderby.out) ,
>> which was suggested by Jack Klebanoff.
>>
>> And I have executed derbylang test and coulud not found error exept
>> for lang/floattypes.sql.
>> I think this error is not caused by my patch.
>>
>> derbylang_report.txt is attached to this mail.
>>
>> Please check this patch from a point of other person's view.
>>
>> best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>
> The latest patch looks good to me. I looked at the changes, applied the
> patch to recently updated Derby source, and successfully ran the
> derbylang test suite. (I did not even see the failure in
> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
> updates I picked up today).
>
> Jack Klebanoff
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
Re: [Patch] Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I have added some test to orderby.sql (and correspond result to
> orderby.out) ,
> which was suggested by Jack Klebanoff.
>
> And I have executed derbylang test and coulud not found error exept
> for lang/floattypes.sql.
> I think this error is not caused by my patch.
>
> derbylang_report.txt is attached to this mail.
>
> Please check this patch from a point of other person's view.
>
> best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
The latest patch looks good to me. I looked at the changes, applied the
patch to recently updated Derby source, and successfully ran the
derbylang test suite. (I did not even see the failure in
lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
updates I picked up today).
Jack Klebanoff
[Patch] Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I have added some test to orderby.sql (and correspond result to orderby.out)
,
which was suggested by Jack Klebanoff.
And I have executed derbylang test and coulud not found error exept for
lang/floattypes.sql.
I think this error is not caused by my patch.
derbylang_report.txt is attached to this mail.
Please check this patch from a point of other person's view.
best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, March 28, 2005 1:14 AM
Subject: Re: About improvement of DERBY-134
> Hello.
>
> I have modified patch for DERBY-134 and solved error at wisconsin.sql .
>
> What I have done was as next.
>
> change-1:
> I made it possible to get value of TableName.hasSchema via
> TableName.hasSchema() method.
> This value seems to indicate whether schema was specified in sql , seeing
> code of sqlgrammer.jj and TableName.java.
>
> change-2:
> Calling method TableName.hasSchema() added by change-1 in
> OrderByColumn.resolveColumnReference(ResultSetNode,ColumnReference).
> If True, pass schemaName to getFromTableByName as schemaName.
> If false, pass null to getFromTableByName as schemaName
>
> This was to make processing as same as original implementation, passing
> schemaName only when it was specified in sql.
>
>
> Test result for winsoncin.sql is as next:
>
> 中山智仁@Arkat ~/derbyUser/wisconsin.20050328
> $ testSql.bat lang/wisconsin.sql
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>set
> DERBY_INSTALL=c:\ProgramDev\derby
> \trunk
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>FOR %X in
> ("c:\ProgramDev\derby\trunk
> ") DO SET DERBY_INSTALL=%~sX
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>SET
> DERBY_INSTALL=c:\PROGRA~2\derby\t
> runk
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>set OLD_CLASSPATH=
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>set
> CLASSPATH=c:\PROGRA~2\derby\trunk
> \tools\java\jakarta-oro-2.0.8.jar;c:\PROGRA~2\derby\trunk\jars\insane\derbynet.j
> ar;c:\PROGRA~2\derby\trunk\jars\insane\derbyTesting.jar;c:\PROGRA~2\derby\trunk\
> jars\insane\derby.jar;c:\PROGRA~2\derby\trunk\jars\insane\derbytools.jar;
>
> c:\ProgramDev\derbyUser\wisconsin.20050328>java
> org.apache.derbyTesting.function
> Tests.harness.RunTest lang/wisconsin.sql
> -- listing properties --
> derby.debug.true=
> derby.storage.checkpointInterval=100000
> derby.language.preloadClasses=true
> *** Start: wisconsin jdk1.5.0_02 2005-03-28 01:00:23 ***
> *** End: wisconsin jdk1.5.0_02 2005-03-28 01:01:47 ***
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, March 26, 2005 1:23 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> Hello.
>>
>> I come to think that this problem seems to happen because of unwannted
>> default schema name.
>>
>> Original before patch code to bind order column uses only schema name ,
>> tablename and column name , contained sql order by clause.
>> If there was no schema name in order clause of processing sql , no schema
>> name , which is null in program , was used to bind.
>>
>> But now, binding process uses value returned via method of
>> ColumnReference
>> .
>> These method returns defalut value ,which is not null , even if user
>> specify no schema name.
>>
>> That does not always cause bug. That is just well-seen default value
>> processing.
>>
>> But some processing of derby seems to run on assumpt that if user specify
>> no schema name, null is passed to bind process.
>>
>> select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x
>>
>> Sql above is one example.
>>
>> Because "t(x)" is not TABLE in DB , t(x) is out of schema.
>> On the other hand "t.x" is handled as "APP.T.x" in ColumnReference.
>> This was turned out by tracing running process by jdb as next
>>
>> main[1] where
>> [1]
>> org.apache.derby.impl.sql.compile.OrderByColumn.resolveColumnReference
>> (OrderByColumn.java:303)
>>
>> <ommited.>
>> main[1] list
>> 299 throw
>> StandardException.newException(SQLState.LANG_QUALIFIED_COLUMN_NAME_NOT_ALLOWED,
>> fullName);
>> 300 }
>> 301
>> 302 if(cr.getTableNameNode() != null){
>> 303 => FromTable fromTable =
>> target.getFromTableByName(cr.getSourceTableName(),
>> 304 cr.getSchemaName(),
>> 305 true);
>> 306 if(fromTable == null){
>> 307 fromTable =
>> target.getFromTableByName(cr.getSourceTableName(),
>> 308 cr.getSchemaName(),
>> main[1] eval cr.getSchemaName()
>> cr.getSchemaName() = "APP"
>> main[1] eval cr.getSourceTableName()
>> cr.getSourceTableName() = "T"
>>
>> Because "t(x)" is out of schema , it is failed to bind "t(x)" with schema
>> name not null.
>>
>> This "APP" was the unwannted default schema name and which cause the
>> problem.
>>
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message -----
>> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Wednesday, March 23, 2005 10:30 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>>I traced running-process using jdb,
>>> and found that FromSubQuery.getFromTableByName(String,String
>>> schemaName,boolean)
>>> seems to be failed ....
>>>
>>>
>>> This method invokes FromTable.getFromTableByName(String,String
>>> schemaName,boolean) ,that is method of super class ,
>>> with schemaName of not-null value.
>>>
>>> org.apache.derby.impl.sql.compile.FromSubQuery L169:
>>> protected FromTable getFromTableByName(String name, String schemaName,
>>> boolean exactMatch)
>>> throws StandardException
>>> {
>>> if (generatedForGroupByClause || generatedForHavingClause)
>>> {
>>> return subquery.getFromTableByName(name, schemaName, exactMatch);
>>> }
>>> else
>>> {
>>> return super.getFromTableByName(name, schemaName, exactMatch); .
>>> }
>>> }
>>>
>>>
>>> But FromTable.getFromTableByName(String,String,boolean) returns null if
>>> schemaName was not null value.
>>>
>>> org.apache.derby.impl.sql.compile.FromTable L1196:
>>> protected FromTable getFromTableByName(String name, String schemaName,
>>> boolean exactMatch)
>>> throws StandardException
>>> {
>>> // Only FromBaseTables have schema names
>>> if (schemaName != null)
>>> {
>>> return null;
>>> }
>>>
>>> if (getExposedName().equals(name))
>>> {
>>> return this;
>>> }
>>> return null;
>>> }
>>>
>>> As shown above , I found comment "Only FromBaseTables have schema names"
>>> in FromTable.getFromTableByName(String,String,boolean).
>>> I think mystery exists around here ....
>>>
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message -----
>>> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Wednesday, March 23, 2005 9:33 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Hello.
>>>>
>>>> Now , updating my local working directory, I could found what was
>>>> happend at Jack's site.
>>>>
>>>> derbylang_report.txt at my site is uploaded next url.
>>>> http://www5.ocn.ne.jp/~tomohito/20050323/derbylang_report.txt
>>>>
>>>>
>>>> If anyone know, could you please give me some more information about
>>>> next ?
>>>>
>>>>>I think that there has been some sort of change in the way the Derby
>>>>>handles binding when there are correlation names.
>>>>
>>>>> It must have been made about a week ago. It has affected some other
>>>>> stuff I am working on. I do not know who made the change, why, or
>>>>> exactly when.
>>>>
>>>>
>>>> The way I bind column in "resolveColumnReference" method was
>>>> based on original "bindOrderByColumn" method,
>>>> just replacing variable "correlationName" and "schemaName" to
>>>> return value of ColumnReference.getSourceTableName() method and
>>>> ColumnReference.getSchemaName() method.
>>>>
>>>> Considering there were no problem before my patch,
>>>> I think there exist some changes in ColumnReference ...
>>>>
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message -----
>>>> From: "Jack Klebanoff" <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Wednesday, March 23, 2005 3:58 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> You may have to do an svn update to bring in the lastest version of
>>>>> the
>>>>> source. I think that there has been some sort of change in the way the
>>>>> Derby handles binding when there are correlation names. Perhaps it is
>>>>> the combination of your changes and these other changes that cause the
>>>>> failure in wisconsin.sql.
>>>>>
>>>>> It must have been made about a week ago. It has affected some other
>>>>> stuff I am working on. I do not know who made the change, why, or
>>>>> exactly when.
>>>>>
>>>>> (Hopefully you will not have to do any merging).
>>>>>
>>>>> Perhaps the lang/orderby.sql tests need to be improved with some cases
>>>>> that use table correlation names in the order by clause. e.g.
>>>>>
>>>>> select * from (values (2),(1)) as t(x) orderby t.x
>>>>> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order
>>>>> by t2.c2,t1.id,t2.c3
>>>>>
>>>>> This is a test of functionality that existed before your changes. Test
>>>>> cases like these probably should have been in lang/orderby.sql before
>>>>> you started.
>>>>>
>>>>> Jack Klebanoff
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> I have tried your small.sql and result was as next.
>>>>>>
>>>>>> --These are evidence for improvement of 134
>>>>>> ij> select * from test_number order by abs(value);
>>>>>> VALUE
>>>>>> -----------
>>>>>> 1
>>>>>> 2
>>>>>> 3
>>>>>>
>>>>>> 3 rows selected
>>>>>> ij> select * from test_number order by value * -1;
>>>>>> VALUE
>>>>>> -----------
>>>>>> 3
>>>>>> 2
>>>>>> 1
>>>>>>
>>>>>> 3 rows selected
>>>>>>
>>>>>> --This is what was written in small.sql
>>>>>> ij> create table TENKTUP1 (
>>>>>> unique1 int not null,
>>>>>> unique2 int not null,
>>>>>> two int,
>>>>>> four int,
>>>>>> ten int,
>>>>>> twenty int,
>>>>>> onePercent int,
>>>>>> tenPercent int,
>>>>>> twentyPercent int,
>>>>>> fiftyPercent int,
>>>>>> unique3 int,
>>>>>> evenOnePercent int,
>>>>>> oddOnePercent int,
>>>>>> stringu1 char(52) not null,
>>>>>> stringu2 char(52) not null,
>>>>>> string4 char(52)
>>>>>> );
>>>>>> 0 rows inserted/updated/deleted
>>>>>> ij> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>> ij>
>>>>>>
>>>>>> Unfortunately, I could not found any ...
>>>>>>
>>>>>> And I attached derbylang_report.txt to this mail.
>>>>>> Can you find any clue in it ?
>>>>>> Are there any difference between yours ?
>>>>>>
>>>>>> If could. I want to yourr derbylang_report...
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>> <kl...@sbcglobal.net>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Tuesday, March 22, 2005 7:33 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite
>>>>>>> suiteName
>>>>>>> writes a test report in suiteName_report.txt. This describes the
>>>>>>> environment, prints a counts of tests that passed and failed, and
>>>>>>> lists
>>>>>>> all the differences from expected in the failed tests. You can also
>>>>>>> find
>>>>>>> lists of passed and failed tests in suiteName_pass.txt and
>>>>>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>>>>>> derby.log files for the failed tests, but you have to dig deeper
>>>>>>> into
>>>>>>> the directories.
>>>>>>>
>>>>>>> When I ran the lang/wisconsin.sql test with your patch it failed.
>>>>>>> The
>>>>>>> query
>>>>>>> get cursor c as
>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>> close c;
>>>>>>> failed to compile, but the test expected it to run. It worked before
>>>>>>> applying the patch, and I believe that it should work.
>>>>>>>
>>>>>>> I boiled the problem down to a small SQL file, which I have
>>>>>>> attached.
>>>>>>> That file should run without error under ij as long as database
>>>>>>> "testdb"
>>>>>>> does not exist when you start ij.
>>>>>>>
>>>>>>> I believe that the problem is with the updated bind method in
>>>>>>> OrderByNode. It does not seem to be able to handle correlation names
>>>>>>> from the FROM list. In the example that failed "t" is not the name
>>>>>>> of
>>>>>>> an
>>>>>>> actual table, but a correlation name used to name the "(values 1)"
>>>>>>> virtual table.
>>>>>>>
>>>>>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>>>>>> expression.bindExcpression and then eliminating most of the code in
>>>>>>> resolveColumnReference. However this does not work either. Then the
>>>>>>> statement
>>>>>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>>>>>> (from the lang/orderby.sql test) fails.
>>>>>>>
>>>>>>> I will work on this some more. Perhaps you can continue looking at
>>>>>>> it
>>>>>>> also.
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> I have tried derbylang test suite , but could not found error which
>>>>>>>> was reported .
>>>>>>>>
>>>>>>>> What I found was just difference around "lang/floattypes.sql".
>>>>>>>> I 'm not sure this is error or not yet.
>>>>>>>>
>>>>>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>>>>>> ====================
>>>>>>>> -- Values clause is a single-row result set, so should not cause
>>>>>>>> optimizer
>>>>>>>> -- to require sort.
>>>>>>>>
>>>>>>>> get cursor c as
>>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>>> close c;
>>>>>>>>
>>>>>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>>>>>
>>>>>>>> commit;
>>>>>>>>
>>>>>>>> -- Try with a join on unique column and order on non-unique column
>>>>>>>> ===================
>>>>>>>> I couldn't find difference between what in your mail.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Next is svn-status of my wisconsin.sql.
>>>>>>>> ===================
>>>>>>>> $ svn status -v wisconsin.sql
>>>>>>>> 157254 122528 djd wisconsin.sql
>>>>>>>> ===================
>>>>>>>>
>>>>>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> Thank you for your checking.
>>>>>>>>>
>>>>>>>>> I did'nt know way to test whole sqls.
>>>>>>>>> Sorry for insufficient test.
>>>>>>>>>
>>>>>>>>> Now I will try whole test.
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql
>>>>>>>>>> test
>>>>>>>>>> failed. The problem output was:
>>>>>>>>>>
>>>>>>>>>> ij> -- Values clause is a single-row result set, so should not
>>>>>>>>>> cause
>>>>>>>>>> optimizer
>>>>>>>>>> -- to require sort.
>>>>>>>>>> get cursor c as
>>>>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in
>>>>>>>>>> which it
>>>>>>>>>> appears.
>>>>>>>>>>
>>>>>>>>>> This error is incorrect.
>>>>>>>>>>
>>>>>>>>>> There must be a problem in the way that the patch binds the ORDER
>>>>>>>>>> BY
>>>>>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>>>>>
>>>>>>>>>> You should probably run at least the derbylang test suite before
>>>>>>>>>> submitting a patch for ORDER BY.
>>>>>>>>>>
>>>>>>>>>> To do this, change into an empty directory and run
>>>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite
>>>>>>>>>> derbylang
>>>>>>>>>> The derbylang suite takes about 90 minutes on my laptop. The
>>>>>>>>>> derbyall
>>>>>>>>>> suite takes 5 or 6 hours.
>>>>>>>>>>
>>>>>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>>>>>> directory and run
>>>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>>>>>> lang/wisconsin.sql
>>>>>>>>>>
>>>>>>>>>> Jack Klebanoff
>>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> Thank for your checking.
>>>>>>>>>>> I have solved the 2 problems.
>>>>>>>>>>> Attached file is new patch.
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The new patch looks much better. However, I found two problems,
>>>>>>>>>>>> one
>>>>>>>>>>>> serious and the other minor.
>>>>>>>>>>>>
>>>>>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails.
>>>>>>>>>>>> The
>>>>>>>>>>>> problem
>>>>>>>>>>>> is in the
>>>>>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>>>>>
>>>>>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>>>> cm)
>>>>>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>>>>>> ClassCastException
>>>>>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>>>>>
>>>>>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to
>>>>>>>>>>>> pass
>>>>>>>>>>>> a
>>>>>>>>>>>> ValueNode. I think that
>>>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>>>> cm),
>>>>>>>>>>>> cm)
>>>>>>>>>>>> works.
>>>>>>>>>>>>
>>>>>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>>>>>> Object
>>>>>>>>>>>> expression) documents a "dummy" parameter that no longer
>>>>>>>>>>>> exists.
>>>>>>>>>>>>
>>>>>>>>>>>> Jack Klebanoff
>>>>>>>>>>>>
>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would you please review it ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just wanted to check how you are progressing on the patch
>>>>>>>>>>>>>> update,
>>>>>>>>>>>>>> following comments by myself and Jack. I do think you are
>>>>>>>>>>>>>> working
>>>>>>>>>>>>>> on an
>>>>>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>>>>>> developpers
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>>>>>> working on
>>>>>>>>>>>>>> this and post any questions or comments you might have. You
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> pretty
>>>>>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am willing to help, if you need any, to continue taking
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> further.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> About 1:
>>>>>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>>>>>> I will try.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> About 2:
>>>>>>>>>>>>>>> Uh oh.
>>>>>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>>>>>> orderby.sql
>>>>>>>>>>>>>>> was needed.....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> About 3:
>>>>>>>>>>>>>>> I see.
>>>>>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>> Based on a quick review, some of the items to be
>>>>>>>>>>>>>>>>>>> completed
>>>>>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the
>>>>>>>>>>>>>>>>>>> way the
>>>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column
>>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions,
>>>>>>>>>>>>>>>>>>> Ex:
>>>>>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>>>>>> non-reserved
>>>>>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens,
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword().
>>>>>>>>>>>>>>>> Having
>>>>>>>>>>>>>>>> to add
>>>>>>>>>>>>>>>> it in two places is difficult enough to discover or
>>>>>>>>>>>>>>>> remember.
>>>>>>>>>>>>>>>> If we
>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only
>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>> of them
>>>>>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>>>>>> sort
>>>>>>>>>>>>>>>> key type. A column name is just one kind of <expression>.
>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> parser
>>>>>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>>>>>> ordering. I
>>>>>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>>> can special case a simple column reference expression, as
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> optimization. This considerably simplifies parsing sort
>>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only sort key type that has to be handled specially is
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> of an
>>>>>>>>>>>>>>>> integer constant. That specifies one of the select list
>>>>>>>>>>>>>>>> columns
>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is
>>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>>>>>> alternative the
>>>>>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>>> by an
>>>>>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>>>>>> determine
>>>>>>>>>>>>>>>> whether the sort key expression is an integer constant, and
>>>>>>>>>>>>>>>> if so
>>>>>>>>>>>>>>>> treat
>>>>>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The two alternatives differ in the way that they treat
>>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>>> integer
>>>>>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows
>>>>>>>>>>>>>>>> by the
>>>>>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY
>>>>>>>>>>>>>>>> 2-1
>>>>>>>>>>>>>>>> ASC"
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If
>>>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>>>> treated
>>>>>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>>>>>> position
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the
>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>>> result
>>>>>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the
>>>>>>>>>>>>>>>> patch to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The new code is
>>>>>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>>>>>> i ++){
>>>>>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>>>>>> break;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>>>>>> indexing. The
>>>>>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be
>>>>>>>>>>>>>>>> "for( i
>>>>>>>>>>>>>>>> = 1;
>>>>>>>>>>>>>>>> i <=
>>>>>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>>>>>> parts of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>>>>>> resulting
>>>>>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>> list,
>>>>>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second
>>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>>> column in
>>>>>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>>>>>> Consider
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of
>>>>>>>>>>>>>>>> type
>>>>>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>>>>>> failing
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>>>>>> ensure
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and
>>>>>>>>>>>>>>>> comma
>>>>>>>>>>>>>>>> separated
>>>>>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jack
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>> connect 'jdbc:derby:testdb;create=true';
>>>>>>> create table TENKTUP1 (
>>>>>>> unique1 int not null,
>>>>>>> unique2 int not null,
>>>>>>> two int,
>>>>>>> four int,
>>>>>>> ten int,
>>>>>>> twenty int,
>>>>>>> onePercent int,
>>>>>>> tenPercent int,
>>>>>>> twentyPercent int,
>>>>>>> fiftyPercent int,
>>>>>>> unique3 int,
>>>>>>> evenOnePercent int,
>>>>>>> oddOnePercent int,
>>>>>>> stringu1 char(52) not null,
>>>>>>> stringu2 char(52) not null,
>>>>>>> string4 char(52)
>>>>>>> );
>>>>>>>
>>>>>>> get cursor c as
>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG Anti-Virus.
>>>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this outgoing message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this outgoing message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>
>>>
>>
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.3 - Release Date: 2005/03/25
>>
>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.3 - Release Date: 2005/03/25
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I have modified patch for DERBY-134 and solved error at wisconsin.sql .
What I have done was as next.
change-1:
I made it possible to get value of TableName.hasSchema via
TableName.hasSchema() method.
This value seems to indicate whether schema was specified in sql , seeing
code of sqlgrammer.jj and TableName.java.
change-2:
Calling method TableName.hasSchema() added by change-1 in
OrderByColumn.resolveColumnReference(ResultSetNode,ColumnReference).
If True, pass schemaName to getFromTableByName as schemaName.
If false, pass null to getFromTableByName as schemaName
This was to make processing as same as original implementation, passing
schemaName only when it was specified in sql.
Test result for winsoncin.sql is as next:
中山智仁@Arkat ~/derbyUser/wisconsin.20050328
$ testSql.bat lang/wisconsin.sql
c:\ProgramDev\derbyUser\wisconsin.20050328>set
DERBY_INSTALL=c:\ProgramDev\derby
\trunk
c:\ProgramDev\derbyUser\wisconsin.20050328>FOR %X in
("c:\ProgramDev\derby\trunk
") DO SET DERBY_INSTALL=%~sX
c:\ProgramDev\derbyUser\wisconsin.20050328>SET
DERBY_INSTALL=c:\PROGRA~2\derby\t
runk
c:\ProgramDev\derbyUser\wisconsin.20050328>set OLD_CLASSPATH=
c:\ProgramDev\derbyUser\wisconsin.20050328>set
CLASSPATH=c:\PROGRA~2\derby\trunk
\tools\java\jakarta-oro-2.0.8.jar;c:\PROGRA~2\derby\trunk\jars\insane\derbynet.j
ar;c:\PROGRA~2\derby\trunk\jars\insane\derbyTesting.jar;c:\PROGRA~2\derby\trunk\
jars\insane\derby.jar;c:\PROGRA~2\derby\trunk\jars\insane\derbytools.jar;
c:\ProgramDev\derbyUser\wisconsin.20050328>java
org.apache.derbyTesting.function
Tests.harness.RunTest lang/wisconsin.sql
-- listing properties --
derby.debug.true=
derby.storage.checkpointInterval=100000
derby.language.preloadClasses=true
*** Start: wisconsin jdk1.5.0_02 2005-03-28 01:00:23 ***
*** End: wisconsin jdk1.5.0_02 2005-03-28 01:01:47 ***
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, March 26, 2005 1:23 AM
Subject: Re: About improvement of DERBY-134
> Hello.
>
> I come to think that this problem seems to happen because of unwannted
> default schema name.
>
> Original before patch code to bind order column uses only schema name ,
> tablename and column name , contained sql order by clause.
> If there was no schema name in order clause of processing sql , no schema
> name , which is null in program , was used to bind.
>
> But now, binding process uses value returned via method of ColumnReference
> .
> These method returns defalut value ,which is not null , even if user
> specify no schema name.
>
> That does not always cause bug. That is just well-seen default value
> processing.
>
> But some processing of derby seems to run on assumpt that if user specify
> no schema name, null is passed to bind process.
>
> select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x
>
> Sql above is one example.
>
> Because "t(x)" is not TABLE in DB , t(x) is out of schema.
> On the other hand "t.x" is handled as "APP.T.x" in ColumnReference.
> This was turned out by tracing running process by jdb as next
>
> main[1] where
> [1]
> org.apache.derby.impl.sql.compile.OrderByColumn.resolveColumnReference
> (OrderByColumn.java:303)
>
> <ommited.>
> main[1] list
> 299 throw
> StandardException.newException(SQLState.LANG_QUALIFIED_COLUMN_NAME_NOT_ALLOWED,
> fullName);
> 300 }
> 301
> 302 if(cr.getTableNameNode() != null){
> 303 => FromTable fromTable =
> target.getFromTableByName(cr.getSourceTableName(),
> 304 cr.getSchemaName(),
> 305 true);
> 306 if(fromTable == null){
> 307 fromTable =
> target.getFromTableByName(cr.getSourceTableName(),
> 308 cr.getSchemaName(),
> main[1] eval cr.getSchemaName()
> cr.getSchemaName() = "APP"
> main[1] eval cr.getSourceTableName()
> cr.getSourceTableName() = "T"
>
> Because "t(x)" is out of schema , it is failed to bind "t(x)" with schema
> name not null.
>
> This "APP" was the unwannted default schema name and which cause the
> problem.
>
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, March 23, 2005 10:30 PM
> Subject: Re: About improvement of DERBY-134
>
>
>>I traced running-process using jdb,
>> and found that FromSubQuery.getFromTableByName(String,String
>> schemaName,boolean)
>> seems to be failed ....
>>
>>
>> This method invokes FromTable.getFromTableByName(String,String
>> schemaName,boolean) ,that is method of super class ,
>> with schemaName of not-null value.
>>
>> org.apache.derby.impl.sql.compile.FromSubQuery L169:
>> protected FromTable getFromTableByName(String name, String schemaName,
>> boolean exactMatch)
>> throws StandardException
>> {
>> if (generatedForGroupByClause || generatedForHavingClause)
>> {
>> return subquery.getFromTableByName(name, schemaName, exactMatch);
>> }
>> else
>> {
>> return super.getFromTableByName(name, schemaName, exactMatch); .
>> }
>> }
>>
>>
>> But FromTable.getFromTableByName(String,String,boolean) returns null if
>> schemaName was not null value.
>>
>> org.apache.derby.impl.sql.compile.FromTable L1196:
>> protected FromTable getFromTableByName(String name, String schemaName,
>> boolean exactMatch)
>> throws StandardException
>> {
>> // Only FromBaseTables have schema names
>> if (schemaName != null)
>> {
>> return null;
>> }
>>
>> if (getExposedName().equals(name))
>> {
>> return this;
>> }
>> return null;
>> }
>>
>> As shown above , I found comment "Only FromBaseTables have schema names"
>> in FromTable.getFromTableByName(String,String,boolean).
>> I think mystery exists around here ....
>>
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message -----
>> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Wednesday, March 23, 2005 9:33 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Hello.
>>>
>>> Now , updating my local working directory, I could found what was
>>> happend at Jack's site.
>>>
>>> derbylang_report.txt at my site is uploaded next url.
>>> http://www5.ocn.ne.jp/~tomohito/20050323/derbylang_report.txt
>>>
>>>
>>> If anyone know, could you please give me some more information about
>>> next ?
>>>
>>>>I think that there has been some sort of change in the way the Derby
>>>>handles binding when there are correlation names.
>>>
>>>> It must have been made about a week ago. It has affected some other
>>>> stuff I am working on. I do not know who made the change, why, or
>>>> exactly when.
>>>
>>>
>>> The way I bind column in "resolveColumnReference" method was
>>> based on original "bindOrderByColumn" method,
>>> just replacing variable "correlationName" and "schemaName" to
>>> return value of ColumnReference.getSourceTableName() method and
>>> ColumnReference.getSchemaName() method.
>>>
>>> Considering there were no problem before my patch,
>>> I think there exist some changes in ColumnReference ...
>>>
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message -----
>>> From: "Jack Klebanoff" <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Wednesday, March 23, 2005 3:58 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> You may have to do an svn update to bring in the lastest version of the
>>>> source. I think that there has been some sort of change in the way the
>>>> Derby handles binding when there are correlation names. Perhaps it is
>>>> the combination of your changes and these other changes that cause the
>>>> failure in wisconsin.sql.
>>>>
>>>> It must have been made about a week ago. It has affected some other
>>>> stuff I am working on. I do not know who made the change, why, or
>>>> exactly when.
>>>>
>>>> (Hopefully you will not have to do any merging).
>>>>
>>>> Perhaps the lang/orderby.sql tests need to be improved with some cases
>>>> that use table correlation names in the order by clause. e.g.
>>>>
>>>> select * from (values (2),(1)) as t(x) orderby t.x
>>>> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order
>>>> by t2.c2,t1.id,t2.c3
>>>>
>>>> This is a test of functionality that existed before your changes. Test
>>>> cases like these probably should have been in lang/orderby.sql before
>>>> you started.
>>>>
>>>> Jack Klebanoff
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> I have tried your small.sql and result was as next.
>>>>>
>>>>> --These are evidence for improvement of 134
>>>>> ij> select * from test_number order by abs(value);
>>>>> VALUE
>>>>> -----------
>>>>> 1
>>>>> 2
>>>>> 3
>>>>>
>>>>> 3 rows selected
>>>>> ij> select * from test_number order by value * -1;
>>>>> VALUE
>>>>> -----------
>>>>> 3
>>>>> 2
>>>>> 1
>>>>>
>>>>> 3 rows selected
>>>>>
>>>>> --This is what was written in small.sql
>>>>> ij> create table TENKTUP1 (
>>>>> unique1 int not null,
>>>>> unique2 int not null,
>>>>> two int,
>>>>> four int,
>>>>> ten int,
>>>>> twenty int,
>>>>> onePercent int,
>>>>> tenPercent int,
>>>>> twentyPercent int,
>>>>> fiftyPercent int,
>>>>> unique3 int,
>>>>> evenOnePercent int,
>>>>> oddOnePercent int,
>>>>> stringu1 char(52) not null,
>>>>> stringu2 char(52) not null,
>>>>> string4 char(52)
>>>>> );
>>>>> 0 rows inserted/updated/deleted
>>>>> ij> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>> ij>
>>>>>
>>>>> Unfortunately, I could not found any ...
>>>>>
>>>>> And I attached derbylang_report.txt to this mail.
>>>>> Can you find any clue in it ?
>>>>> Are there any difference between yours ?
>>>>>
>>>>> If could. I want to yourr derbylang_report...
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Tuesday, March 22, 2005 7:33 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>>>>>> writes a test report in suiteName_report.txt. This describes the
>>>>>> environment, prints a counts of tests that passed and failed, and
>>>>>> lists
>>>>>> all the differences from expected in the failed tests. You can also
>>>>>> find
>>>>>> lists of passed and failed tests in suiteName_pass.txt and
>>>>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>>>>> derby.log files for the failed tests, but you have to dig deeper into
>>>>>> the directories.
>>>>>>
>>>>>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>>>>>> query
>>>>>> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>> close c;
>>>>>> failed to compile, but the test expected it to run. It worked before
>>>>>> applying the patch, and I believe that it should work.
>>>>>>
>>>>>> I boiled the problem down to a small SQL file, which I have attached.
>>>>>> That file should run without error under ij as long as database
>>>>>> "testdb"
>>>>>> does not exist when you start ij.
>>>>>>
>>>>>> I believe that the problem is with the updated bind method in
>>>>>> OrderByNode. It does not seem to be able to handle correlation names
>>>>>> from the FROM list. In the example that failed "t" is not the name of
>>>>>> an
>>>>>> actual table, but a correlation name used to name the "(values 1)"
>>>>>> virtual table.
>>>>>>
>>>>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>>>>> expression.bindExcpression and then eliminating most of the code in
>>>>>> resolveColumnReference. However this does not work either. Then the
>>>>>> statement
>>>>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>>>>> (from the lang/orderby.sql test) fails.
>>>>>>
>>>>>> I will work on this some more. Perhaps you can continue looking at it
>>>>>> also.
>>>>>>
>>>>>> Jack
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> I have tried derbylang test suite , but could not found error which
>>>>>>> was reported .
>>>>>>>
>>>>>>> What I found was just difference around "lang/floattypes.sql".
>>>>>>> I 'm not sure this is error or not yet.
>>>>>>>
>>>>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>>>>> ====================
>>>>>>> -- Values clause is a single-row result set, so should not cause
>>>>>>> optimizer
>>>>>>> -- to require sort.
>>>>>>>
>>>>>>> get cursor c as
>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>> close c;
>>>>>>>
>>>>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>>>>
>>>>>>> commit;
>>>>>>>
>>>>>>> -- Try with a join on unique column and order on non-unique column
>>>>>>> ===================
>>>>>>> I couldn't find difference between what in your mail.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Next is svn-status of my wisconsin.sql.
>>>>>>> ===================
>>>>>>> $ svn status -v wisconsin.sql
>>>>>>> 157254 122528 djd wisconsin.sql
>>>>>>> ===================
>>>>>>>
>>>>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> Thank you for your checking.
>>>>>>>>
>>>>>>>> I did'nt know way to test whole sqls.
>>>>>>>> Sorry for insufficient test.
>>>>>>>>
>>>>>>>> Now I will try whole test.
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql
>>>>>>>>> test
>>>>>>>>> failed. The problem output was:
>>>>>>>>>
>>>>>>>>> ij> -- Values clause is a single-row result set, so should not
>>>>>>>>> cause
>>>>>>>>> optimizer
>>>>>>>>> -- to require sort.
>>>>>>>>> get cursor c as
>>>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in
>>>>>>>>> which it
>>>>>>>>> appears.
>>>>>>>>>
>>>>>>>>> This error is incorrect.
>>>>>>>>>
>>>>>>>>> There must be a problem in the way that the patch binds the ORDER
>>>>>>>>> BY
>>>>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>>>>
>>>>>>>>> You should probably run at least the derbylang test suite before
>>>>>>>>> submitting a patch for ORDER BY.
>>>>>>>>>
>>>>>>>>> To do this, change into an empty directory and run
>>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite
>>>>>>>>> derbylang
>>>>>>>>> The derbylang suite takes about 90 minutes on my laptop. The
>>>>>>>>> derbyall
>>>>>>>>> suite takes 5 or 6 hours.
>>>>>>>>>
>>>>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>>>>> directory and run
>>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>>>>> lang/wisconsin.sql
>>>>>>>>>
>>>>>>>>> Jack Klebanoff
>>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> Thank for your checking.
>>>>>>>>>> I have solved the 2 problems.
>>>>>>>>>> Attached file is new patch.
>>>>>>>>>>
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The new patch looks much better. However, I found two problems,
>>>>>>>>>>> one
>>>>>>>>>>> serious and the other minor.
>>>>>>>>>>>
>>>>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>>>>>> problem
>>>>>>>>>>> is in the
>>>>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>>>>
>>>>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>>> cm)
>>>>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>>>>> ClassCastException
>>>>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>>>>
>>>>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass
>>>>>>>>>>> a
>>>>>>>>>>> ValueNode. I think that
>>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>>> cm),
>>>>>>>>>>> cm)
>>>>>>>>>>> works.
>>>>>>>>>>>
>>>>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>>>>> Object
>>>>>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>>>>>
>>>>>>>>>>> Jack Klebanoff
>>>>>>>>>>>
>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>>
>>>>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>>>>
>>>>>>>>>>>> Would you please review it ?
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just wanted to check how you are progressing on the patch
>>>>>>>>>>>>> update,
>>>>>>>>>>>>> following comments by myself and Jack. I do think you are
>>>>>>>>>>>>> working
>>>>>>>>>>>>> on an
>>>>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>>>>> developpers
>>>>>>>>>>>>> have
>>>>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>>>>> working on
>>>>>>>>>>>>> this and post any questions or comments you might have. You
>>>>>>>>>>>>> are
>>>>>>>>>>>>> pretty
>>>>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>>>>>> further.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About 1:
>>>>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>>>>> I will try.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About 2:
>>>>>>>>>>>>>> Uh oh.
>>>>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>>>>> orderby.sql
>>>>>>>>>>>>>> was needed.....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About 3:
>>>>>>>>>>>>>> I see.
>>>>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>> Based on a quick review, some of the items to be
>>>>>>>>>>>>>>>>>> completed
>>>>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the
>>>>>>>>>>>>>>>>>> way the
>>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column
>>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions,
>>>>>>>>>>>>>>>>>> Ex:
>>>>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have
>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>>>>> non-reserved
>>>>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens,
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword().
>>>>>>>>>>>>>>> Having
>>>>>>>>>>>>>>> to add
>>>>>>>>>>>>>>> it in two places is difficult enough to discover or
>>>>>>>>>>>>>>> remember.
>>>>>>>>>>>>>>> If we
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>>>>>> of them
>>>>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>>>>> sort
>>>>>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> parser
>>>>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>>>>> ordering. I
>>>>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>>> class
>>>>>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>>>>>> optimization. This considerably simplifies parsing sort
>>>>>>>>>>>>>>> keys.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only sort key type that has to be handled specially is
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> of an
>>>>>>>>>>>>>>> integer constant. That specifies one of the select list
>>>>>>>>>>>>>>> columns
>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is
>>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>>>>> alternative the
>>>>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>>>>> given
>>>>>>>>>>>>>>> by an
>>>>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>>>>> determine
>>>>>>>>>>>>>>> whether the sort key expression is an integer constant, and
>>>>>>>>>>>>>>> if so
>>>>>>>>>>>>>>> treat
>>>>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The two alternatives differ in the way that they treat
>>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>>> integer
>>>>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows
>>>>>>>>>>>>>>> by the
>>>>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY
>>>>>>>>>>>>>>> 2-1
>>>>>>>>>>>>>>> ASC"
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If
>>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>>> treated
>>>>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>>>>> position
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the
>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>> result
>>>>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the
>>>>>>>>>>>>>>> patch to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The new code is
>>>>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>>>>> i ++){
>>>>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>>>>> break;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>>>>> indexing. The
>>>>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be
>>>>>>>>>>>>>>> "for( i
>>>>>>>>>>>>>>> = 1;
>>>>>>>>>>>>>>> i <=
>>>>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>>>>> parts of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>>>>> resulting
>>>>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>> list,
>>>>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second
>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>> column in
>>>>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>>>>> Consider
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of
>>>>>>>>>>>>>>> type
>>>>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>>>>> failing
>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>>>>> ensure
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and
>>>>>>>>>>>>>>> comma
>>>>>>>>>>>>>>> separated
>>>>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jack
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>> connect 'jdbc:derby:testdb;create=true';
>>>>>> create table TENKTUP1 (
>>>>>> unique1 int not null,
>>>>>> unique2 int not null,
>>>>>> two int,
>>>>>> four int,
>>>>>> ten int,
>>>>>> twenty int,
>>>>>> onePercent int,
>>>>>> tenPercent int,
>>>>>> twentyPercent int,
>>>>>> fiftyPercent int,
>>>>>> unique3 int,
>>>>>> evenOnePercent int,
>>>>>> oddOnePercent int,
>>>>>> stringu1 char(52) not null,
>>>>>> stringu2 char(52) not null,
>>>>>> string4 char(52)
>>>>>> );
>>>>>>
>>>>>> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this outgoing message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>
>>
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.3 - Release Date: 2005/03/25
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I come to think that this problem seems to happen because of unwannted
default schema name.
Original before patch code to bind order column uses only schema name ,
tablename and column name , contained sql order by clause.
If there was no schema name in order clause of processing sql , no schema
name , which is null in program , was used to bind.
But now, binding process uses value returned via method of ColumnReference .
These method returns defalut value ,which is not null , even if user specify
no schema name.
That does not always cause bug. That is just well-seen default value
processing.
But some processing of derby seems to run on assumpt that if user specify no
schema name, null is passed to bind process.
select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x
Sql above is one example.
Because "t(x)" is not TABLE in DB , t(x) is out of schema.
On the other hand "t.x" is handled as "APP.T.x" in ColumnReference.
This was turned out by tracing running process by jdb as next
main[1] where
[1] org.apache.derby.impl.sql.compile.OrderByColumn.resolveColumnReference
(OrderByColumn.java:303)
<ommited.>
main[1] list
299 throw
StandardException.newException(SQLState.LANG_QUALIFIED_COLUMN_NAME_NOT_ALLOWED,
fullName);
300 }
301
302 if(cr.getTableNameNode() != null){
303 => FromTable fromTable =
target.getFromTableByName(cr.getSourceTableName(),
304
cr.getSchemaName(),
305
true);
306 if(fromTable == null){
307 fromTable =
target.getFromTableByName(cr.getSourceTableName(),
308
cr.getSchemaName(),
main[1] eval cr.getSchemaName()
cr.getSchemaName() = "APP"
main[1] eval cr.getSourceTableName()
cr.getSourceTableName() = "T"
Because "t(x)" is out of schema , it is failed to bind "t(x)" with schema
name not null.
This "APP" was the unwannted default schema name and which cause the
problem.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, March 23, 2005 10:30 PM
Subject: Re: About improvement of DERBY-134
>I traced running-process using jdb,
> and found that FromSubQuery.getFromTableByName(String,String
> schemaName,boolean)
> seems to be failed ....
>
>
> This method invokes FromTable.getFromTableByName(String,String
> schemaName,boolean) ,that is method of super class ,
> with schemaName of not-null value.
>
> org.apache.derby.impl.sql.compile.FromSubQuery L169:
> protected FromTable getFromTableByName(String name, String schemaName,
> boolean exactMatch)
> throws StandardException
> {
> if (generatedForGroupByClause || generatedForHavingClause)
> {
> return subquery.getFromTableByName(name, schemaName, exactMatch);
> }
> else
> {
> return super.getFromTableByName(name, schemaName, exactMatch); .
> }
> }
>
>
> But FromTable.getFromTableByName(String,String,boolean) returns null if
> schemaName was not null value.
>
> org.apache.derby.impl.sql.compile.FromTable L1196:
> protected FromTable getFromTableByName(String name, String schemaName,
> boolean exactMatch)
> throws StandardException
> {
> // Only FromBaseTables have schema names
> if (schemaName != null)
> {
> return null;
> }
>
> if (getExposedName().equals(name))
> {
> return this;
> }
> return null;
> }
>
> As shown above , I found comment "Only FromBaseTables have schema names"
> in FromTable.getFromTableByName(String,String,boolean).
> I think mystery exists around here ....
>
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, March 23, 2005 9:33 PM
> Subject: Re: About improvement of DERBY-134
>
>
>> Hello.
>>
>> Now , updating my local working directory, I could found what was happend
>> at Jack's site.
>>
>> derbylang_report.txt at my site is uploaded next url.
>> http://www5.ocn.ne.jp/~tomohito/20050323/derbylang_report.txt
>>
>>
>> If anyone know, could you please give me some more information about next
>> ?
>>
>>>I think that there has been some sort of change in the way the Derby
>>>handles binding when there are correlation names.
>>
>>> It must have been made about a week ago. It has affected some other
>>> stuff I am working on. I do not know who made the change, why, or
>>> exactly when.
>>
>>
>> The way I bind column in "resolveColumnReference" method was
>> based on original "bindOrderByColumn" method,
>> just replacing variable "correlationName" and "schemaName" to
>> return value of ColumnReference.getSourceTableName() method and
>> ColumnReference.getSchemaName() method.
>>
>> Considering there were no problem before my patch,
>> I think there exist some changes in ColumnReference ...
>>
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message -----
>> From: "Jack Klebanoff" <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Wednesday, March 23, 2005 3:58 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> You may have to do an svn update to bring in the lastest version of the
>>> source. I think that there has been some sort of change in the way the
>>> Derby handles binding when there are correlation names. Perhaps it is
>>> the combination of your changes and these other changes that cause the
>>> failure in wisconsin.sql.
>>>
>>> It must have been made about a week ago. It has affected some other
>>> stuff I am working on. I do not know who made the change, why, or
>>> exactly when.
>>>
>>> (Hopefully you will not have to do any merging).
>>>
>>> Perhaps the lang/orderby.sql tests need to be improved with some cases
>>> that use table correlation names in the order by clause. e.g.
>>>
>>> select * from (values (2),(1)) as t(x) orderby t.x
>>> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order by
>>> t2.c2,t1.id,t2.c3
>>>
>>> This is a test of functionality that existed before your changes. Test
>>> cases like these probably should have been in lang/orderby.sql before
>>> you started.
>>>
>>> Jack Klebanoff
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> I have tried your small.sql and result was as next.
>>>>
>>>> --These are evidence for improvement of 134
>>>> ij> select * from test_number order by abs(value);
>>>> VALUE
>>>> -----------
>>>> 1
>>>> 2
>>>> 3
>>>>
>>>> 3 rows selected
>>>> ij> select * from test_number order by value * -1;
>>>> VALUE
>>>> -----------
>>>> 3
>>>> 2
>>>> 1
>>>>
>>>> 3 rows selected
>>>>
>>>> --This is what was written in small.sql
>>>> ij> create table TENKTUP1 (
>>>> unique1 int not null,
>>>> unique2 int not null,
>>>> two int,
>>>> four int,
>>>> ten int,
>>>> twenty int,
>>>> onePercent int,
>>>> tenPercent int,
>>>> twentyPercent int,
>>>> fiftyPercent int,
>>>> unique3 int,
>>>> evenOnePercent int,
>>>> oddOnePercent int,
>>>> stringu1 char(52) not null,
>>>> stringu2 char(52) not null,
>>>> string4 char(52)
>>>> );
>>>> 0 rows inserted/updated/deleted
>>>> ij> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> ij>
>>>>
>>>> Unfortunately, I could not found any ...
>>>>
>>>> And I attached derbylang_report.txt to this mail.
>>>> Can you find any clue in it ?
>>>> Are there any difference between yours ?
>>>>
>>>> If could. I want to yourr derbylang_report...
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Tuesday, March 22, 2005 7:33 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>>>>> writes a test report in suiteName_report.txt. This describes the
>>>>> environment, prints a counts of tests that passed and failed, and
>>>>> lists
>>>>> all the differences from expected in the failed tests. You can also
>>>>> find
>>>>> lists of passed and failed tests in suiteName_pass.txt and
>>>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>>>> derby.log files for the failed tests, but you have to dig deeper into
>>>>> the directories.
>>>>>
>>>>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>>>>> query
>>>>> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>> close c;
>>>>> failed to compile, but the test expected it to run. It worked before
>>>>> applying the patch, and I believe that it should work.
>>>>>
>>>>> I boiled the problem down to a small SQL file, which I have attached.
>>>>> That file should run without error under ij as long as database
>>>>> "testdb"
>>>>> does not exist when you start ij.
>>>>>
>>>>> I believe that the problem is with the updated bind method in
>>>>> OrderByNode. It does not seem to be able to handle correlation names
>>>>> from the FROM list. In the example that failed "t" is not the name of
>>>>> an
>>>>> actual table, but a correlation name used to name the "(values 1)"
>>>>> virtual table.
>>>>>
>>>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>>>> expression.bindExcpression and then eliminating most of the code in
>>>>> resolveColumnReference. However this does not work either. Then the
>>>>> statement
>>>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>>>> (from the lang/orderby.sql test) fails.
>>>>>
>>>>> I will work on this some more. Perhaps you can continue looking at it
>>>>> also.
>>>>>
>>>>> Jack
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> I have tried derbylang test suite , but could not found error which
>>>>>> was reported .
>>>>>>
>>>>>> What I found was just difference around "lang/floattypes.sql".
>>>>>> I 'm not sure this is error or not yet.
>>>>>>
>>>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>>>> ====================
>>>>>> -- Values clause is a single-row result set, so should not cause
>>>>>> optimizer
>>>>>> -- to require sort.
>>>>>>
>>>>>> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>> close c;
>>>>>>
>>>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>>>
>>>>>> commit;
>>>>>>
>>>>>> -- Try with a join on unique column and order on non-unique column
>>>>>> ===================
>>>>>> I couldn't find difference between what in your mail.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Next is svn-status of my wisconsin.sql.
>>>>>> ===================
>>>>>> $ svn status -v wisconsin.sql
>>>>>> 157254 122528 djd wisconsin.sql
>>>>>> ===================
>>>>>>
>>>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> Thank you for your checking.
>>>>>>>
>>>>>>> I did'nt know way to test whole sqls.
>>>>>>> Sorry for insufficient test.
>>>>>>>
>>>>>>> Now I will try whole test.
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>> <kl...@sbcglobal.net>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql
>>>>>>>> test
>>>>>>>> failed. The problem output was:
>>>>>>>>
>>>>>>>> ij> -- Values clause is a single-row result set, so should not
>>>>>>>> cause
>>>>>>>> optimizer
>>>>>>>> -- to require sort.
>>>>>>>> get cursor c as
>>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which
>>>>>>>> it
>>>>>>>> appears.
>>>>>>>>
>>>>>>>> This error is incorrect.
>>>>>>>>
>>>>>>>> There must be a problem in the way that the patch binds the ORDER
>>>>>>>> BY
>>>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>>>
>>>>>>>> You should probably run at least the derbylang test suite before
>>>>>>>> submitting a patch for ORDER BY.
>>>>>>>>
>>>>>>>> To do this, change into an empty directory and run
>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite
>>>>>>>> derbylang
>>>>>>>> The derbylang suite takes about 90 minutes on my laptop. The
>>>>>>>> derbyall
>>>>>>>> suite takes 5 or 6 hours.
>>>>>>>>
>>>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>>>> directory and run
>>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>>>> lang/wisconsin.sql
>>>>>>>>
>>>>>>>> Jack Klebanoff
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> Thank for your checking.
>>>>>>>>> I have solved the 2 problems.
>>>>>>>>> Attached file is new patch.
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The new patch looks much better. However, I found two problems,
>>>>>>>>>> one
>>>>>>>>>> serious and the other minor.
>>>>>>>>>>
>>>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>>>>> problem
>>>>>>>>>> is in the
>>>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>>>
>>>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>> cm)
>>>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>>>> ClassCastException
>>>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>>>
>>>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass
>>>>>>>>>> a
>>>>>>>>>> ValueNode. I think that
>>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>>> cm),
>>>>>>>>>> cm)
>>>>>>>>>> works.
>>>>>>>>>>
>>>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>>>> Object
>>>>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>>>>
>>>>>>>>>> Jack Klebanoff
>>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>>>
>>>>>>>>>>> Would you please review it ?
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>>>
>>>>>>>>>>>> Just wanted to check how you are progressing on the patch
>>>>>>>>>>>> update,
>>>>>>>>>>>> following comments by myself and Jack. I do think you are
>>>>>>>>>>>> working
>>>>>>>>>>>> on an
>>>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>>>> developpers
>>>>>>>>>>>> have
>>>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>>>> working on
>>>>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>>>>> pretty
>>>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>>>
>>>>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>>>>> further.
>>>>>>>>>>>>
>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>
>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> About 1:
>>>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>>>> I will try.
>>>>>>>>>>>>>
>>>>>>>>>>>>> About 2:
>>>>>>>>>>>>> Uh oh.
>>>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>>>> orderby.sql
>>>>>>>>>>>>> was needed.....
>>>>>>>>>>>>>
>>>>>>>>>>>>> About 3:
>>>>>>>>>>>>> I see.
>>>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>>>> non-reserved
>>>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword().
>>>>>>>>>>>>>> Having
>>>>>>>>>>>>>> to add
>>>>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>>>>> If we
>>>>>>>>>>>>>> need
>>>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>>>>> of them
>>>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>>>> sort
>>>>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> parser
>>>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>>>> ordering. I
>>>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>> class
>>>>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only sort key type that has to be handled specially is
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> of an
>>>>>>>>>>>>>> integer constant. That specifies one of the select list
>>>>>>>>>>>>>> columns
>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is
>>>>>>>>>>>>>> done
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>>>> alternative the
>>>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>>>> given
>>>>>>>>>>>>>> by an
>>>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>>>> determine
>>>>>>>>>>>>>> whether the sort key expression is an integer constant, and
>>>>>>>>>>>>>> if so
>>>>>>>>>>>>>> treat
>>>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The two alternatives differ in the way that they treat
>>>>>>>>>>>>>> constant
>>>>>>>>>>>>>> integer
>>>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY
>>>>>>>>>>>>>> 2-1
>>>>>>>>>>>>>> ASC"
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If
>>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>>> treated
>>>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>>>> position
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the
>>>>>>>>>>>>>> first
>>>>>>>>>>>>>> result
>>>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the
>>>>>>>>>>>>>> patch to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The new code is
>>>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>>>> i ++){
>>>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>>>> break;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>>>> indexing. The
>>>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be
>>>>>>>>>>>>>> "for( i
>>>>>>>>>>>>>> = 1;
>>>>>>>>>>>>>> i <=
>>>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>>>> parts of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>>>> resulting
>>>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>>>> target
>>>>>>>>>>>>>> list,
>>>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>>>>> column in
>>>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>>>> Consider
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of
>>>>>>>>>>>>>> type
>>>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>>>> failing
>>>>>>>>>>>>>> case
>>>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>>>> ensure
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>>>>> separated
>>>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jack
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>> connect 'jdbc:derby:testdb;create=true';
>>>>> create table TENKTUP1 (
>>>>> unique1 int not null,
>>>>> unique2 int not null,
>>>>> two int,
>>>>> four int,
>>>>> ten int,
>>>>> twenty int,
>>>>> onePercent int,
>>>>> tenPercent int,
>>>>> twentyPercent int,
>>>>> fiftyPercent int,
>>>>> unique3 int,
>>>>> evenOnePercent int,
>>>>> oddOnePercent int,
>>>>> stringu1 char(52) not null,
>>>>> stringu2 char(52) not null,
>>>>> string4 char(52)
>>>>> );
>>>>>
>>>>> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>>
>>>
>>
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
I traced running-process using jdb,
and found that FromSubQuery.getFromTableByName(String,String
schemaName,boolean)
seems to be failed ....
This method invokes FromTable.getFromTableByName(String,String
schemaName,boolean) ,that is method of super class ,
with schemaName of not-null value.
org.apache.derby.impl.sql.compile.FromSubQuery L169:
protected FromTable getFromTableByName(String name, String schemaName,
boolean exactMatch)
throws StandardException
{
if (generatedForGroupByClause || generatedForHavingClause)
{
return subquery.getFromTableByName(name, schemaName, exactMatch);
}
else
{
return super.getFromTableByName(name, schemaName, exactMatch); .
}
}
But FromTable.getFromTableByName(String,String,boolean) returns null if
schemaName was not null value.
org.apache.derby.impl.sql.compile.FromTable L1196:
protected FromTable getFromTableByName(String name, String schemaName,
boolean exactMatch)
throws StandardException
{
// Only FromBaseTables have schema names
if (schemaName != null)
{
return null;
}
if (getExposedName().equals(name))
{
return this;
}
return null;
}
As shown above , I found comment "Only FromBaseTables have schema names" in
FromTable.getFromTableByName(String,String,boolean).
I think mystery exists around here ....
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, March 23, 2005 9:33 PM
Subject: Re: About improvement of DERBY-134
> Hello.
>
> Now , updating my local working directory, I could found what was happend
> at Jack's site.
>
> derbylang_report.txt at my site is uploaded next url.
> http://www5.ocn.ne.jp/~tomohito/20050323/derbylang_report.txt
>
>
> If anyone know, could you please give me some more information about next
> ?
>
>>I think that there has been some sort of change in the way the Derby
>>handles binding when there are correlation names.
>
>> It must have been made about a week ago. It has affected some other stuff
>> I am working on. I do not know who made the change, why, or exactly when.
>
>
> The way I bind column in "resolveColumnReference" method was
> based on original "bindOrderByColumn" method,
> just replacing variable "correlationName" and "schemaName" to
> return value of ColumnReference.getSourceTableName() method and
> ColumnReference.getSchemaName() method.
>
> Considering there were no problem before my patch,
> I think there exist some changes in ColumnReference ...
>
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Jack Klebanoff" <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, March 23, 2005 3:58 PM
> Subject: Re: About improvement of DERBY-134
>
>
>> You may have to do an svn update to bring in the lastest version of the
>> source. I think that there has been some sort of change in the way the
>> Derby handles binding when there are correlation names. Perhaps it is the
>> combination of your changes and these other changes that cause the
>> failure in wisconsin.sql.
>>
>> It must have been made about a week ago. It has affected some other stuff
>> I am working on. I do not know who made the change, why, or exactly when.
>>
>> (Hopefully you will not have to do any merging).
>>
>> Perhaps the lang/orderby.sql tests need to be improved with some cases
>> that use table correlation names in the order by clause. e.g.
>>
>> select * from (values (2),(1)) as t(x) orderby t.x
>> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order by
>> t2.c2,t1.id,t2.c3
>>
>> This is a test of functionality that existed before your changes. Test
>> cases like these probably should have been in lang/orderby.sql before you
>> started.
>>
>> Jack Klebanoff
>>
>> TomohitoNakayama wrote:
>>
>>> I have tried your small.sql and result was as next.
>>>
>>> --These are evidence for improvement of 134
>>> ij> select * from test_number order by abs(value);
>>> VALUE
>>> -----------
>>> 1
>>> 2
>>> 3
>>>
>>> 3 rows selected
>>> ij> select * from test_number order by value * -1;
>>> VALUE
>>> -----------
>>> 3
>>> 2
>>> 1
>>>
>>> 3 rows selected
>>>
>>> --This is what was written in small.sql
>>> ij> create table TENKTUP1 (
>>> unique1 int not null,
>>> unique2 int not null,
>>> two int,
>>> four int,
>>> ten int,
>>> twenty int,
>>> onePercent int,
>>> tenPercent int,
>>> twentyPercent int,
>>> fiftyPercent int,
>>> unique3 int,
>>> evenOnePercent int,
>>> oddOnePercent int,
>>> stringu1 char(52) not null,
>>> stringu2 char(52) not null,
>>> string4 char(52)
>>> );
>>> 0 rows inserted/updated/deleted
>>> ij> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> ij>
>>>
>>> Unfortunately, I could not found any ...
>>>
>>> And I attached derbylang_report.txt to this mail.
>>> Can you find any clue in it ?
>>> Are there any difference between yours ?
>>>
>>> If could. I want to yourr derbylang_report...
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Tuesday, March 22, 2005 7:33 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>>>> writes a test report in suiteName_report.txt. This describes the
>>>> environment, prints a counts of tests that passed and failed, and lists
>>>> all the differences from expected in the failed tests. You can also
>>>> find
>>>> lists of passed and failed tests in suiteName_pass.txt and
>>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>>> derby.log files for the failed tests, but you have to dig deeper into
>>>> the directories.
>>>>
>>>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>>>> query
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> close c;
>>>> failed to compile, but the test expected it to run. It worked before
>>>> applying the patch, and I believe that it should work.
>>>>
>>>> I boiled the problem down to a small SQL file, which I have attached.
>>>> That file should run without error under ij as long as database
>>>> "testdb"
>>>> does not exist when you start ij.
>>>>
>>>> I believe that the problem is with the updated bind method in
>>>> OrderByNode. It does not seem to be able to handle correlation names
>>>> from the FROM list. In the example that failed "t" is not the name of
>>>> an
>>>> actual table, but a correlation name used to name the "(values 1)"
>>>> virtual table.
>>>>
>>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>>> expression.bindExcpression and then eliminating most of the code in
>>>> resolveColumnReference. However this does not work either. Then the
>>>> statement
>>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>>> (from the lang/orderby.sql test) fails.
>>>>
>>>> I will work on this some more. Perhaps you can continue looking at it
>>>> also.
>>>>
>>>> Jack
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> I have tried derbylang test suite , but could not found error which
>>>>> was reported .
>>>>>
>>>>> What I found was just difference around "lang/floattypes.sql".
>>>>> I 'm not sure this is error or not yet.
>>>>>
>>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>>> ====================
>>>>> -- Values clause is a single-row result set, so should not cause
>>>>> optimizer
>>>>> -- to require sort.
>>>>>
>>>>> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>> close c;
>>>>>
>>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>>
>>>>> commit;
>>>>>
>>>>> -- Try with a join on unique column and order on non-unique column
>>>>> ===================
>>>>> I couldn't find difference between what in your mail.
>>>>>
>>>>>
>>>>>
>>>>> Next is svn-status of my wisconsin.sql.
>>>>> ===================
>>>>> $ svn status -v wisconsin.sql
>>>>> 157254 122528 djd wisconsin.sql
>>>>> ===================
>>>>>
>>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Thank you for your checking.
>>>>>>
>>>>>> I did'nt know way to test whole sqls.
>>>>>> Sorry for insufficient test.
>>>>>>
>>>>>> Now I will try whole test.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>> <kl...@sbcglobal.net>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>>>>> failed. The problem output was:
>>>>>>>
>>>>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>>>>> optimizer
>>>>>>> -- to require sort.
>>>>>>> get cursor c as
>>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>>> where TENKTUP1.unique1 = t.x
>>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which
>>>>>>> it
>>>>>>> appears.
>>>>>>>
>>>>>>> This error is incorrect.
>>>>>>>
>>>>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>>
>>>>>>> You should probably run at least the derbylang test suite before
>>>>>>> submitting a patch for ORDER BY.
>>>>>>>
>>>>>>> To do this, change into an empty directory and run
>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite
>>>>>>> derbylang
>>>>>>> The derbylang suite takes about 90 minutes on my laptop. The
>>>>>>> derbyall
>>>>>>> suite takes 5 or 6 hours.
>>>>>>>
>>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>>> directory and run
>>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>>> lang/wisconsin.sql
>>>>>>>
>>>>>>> Jack Klebanoff
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> Thank for your checking.
>>>>>>>> I have solved the 2 problems.
>>>>>>>> Attached file is new patch.
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> The new patch looks much better. However, I found two problems,
>>>>>>>>> one
>>>>>>>>> serious and the other minor.
>>>>>>>>>
>>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>>>> problem
>>>>>>>>> is in the
>>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>>
>>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>> cm)
>>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>>> ClassCastException
>>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>>
>>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>>>>> ValueNode. I think that
>>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>>> cm),
>>>>>>>>> cm)
>>>>>>>>> works.
>>>>>>>>>
>>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>>> Object
>>>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>>>
>>>>>>>>> Jack Klebanoff
>>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>>
>>>>>>>>>> Would you please review it ?
>>>>>>>>>>
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>>
>>>>>>>>>>> Just wanted to check how you are progressing on the patch
>>>>>>>>>>> update,
>>>>>>>>>>> following comments by myself and Jack. I do think you are
>>>>>>>>>>> working
>>>>>>>>>>> on an
>>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>>> developpers
>>>>>>>>>>> have
>>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>>> working on
>>>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>>>> pretty
>>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>>
>>>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>>>> further.
>>>>>>>>>>>
>>>>>>>>>>> Satheesh
>>>>>>>>>>>
>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>>
>>>>>>>>>>>> About 1:
>>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>>> I will try.
>>>>>>>>>>>>
>>>>>>>>>>>> About 2:
>>>>>>>>>>>> Uh oh.
>>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>>> orderby.sql
>>>>>>>>>>>> was needed.....
>>>>>>>>>>>>
>>>>>>>>>>>> About 3:
>>>>>>>>>>>> I see.
>>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>>
>>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a
>>>>>>>>>>>>>>>> case
>>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have
>>>>>>>>>>>>> even
>>>>>>>>>>>>> fixed
>>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>>> patch.
>>>>>>>>>>>>> It is
>>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>>> non-reserved
>>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a
>>>>>>>>>>>>> new
>>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword().
>>>>>>>>>>>>> Having
>>>>>>>>>>>>> to add
>>>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>>>> If we
>>>>>>>>>>>>> need
>>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>>>> of them
>>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>>> sort
>>>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>>>> the
>>>>>>>>>>>>> parser
>>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>>> ordering. I
>>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>> class
>>>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only sort key type that has to be handled specially is
>>>>>>>>>>>>> that
>>>>>>>>>>>>> of an
>>>>>>>>>>>>> integer constant. That specifies one of the select list
>>>>>>>>>>>>> columns
>>>>>>>>>>>>> as the
>>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is
>>>>>>>>>>>>> done
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>>> alternative the
>>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>>> given
>>>>>>>>>>>>> by an
>>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>>> determine
>>>>>>>>>>>>> whether the sort key expression is an integer constant, and if
>>>>>>>>>>>>> so
>>>>>>>>>>>>> treat
>>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The two alternatives differ in the way that they treat
>>>>>>>>>>>>> constant
>>>>>>>>>>>>> integer
>>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by
>>>>>>>>>>>>> the
>>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>>>>> ASC"
>>>>>>>>>>>>> and
>>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If
>>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>>> treated
>>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>>> position
>>>>>>>>>>>>> then
>>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>>>>> result
>>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The new code is
>>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>>
>>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>>
>>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>>> i ++){
>>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>>> break;
>>>>>>>>>>>>> }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>>> indexing. The
>>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>>>>> = 1;
>>>>>>>>>>>>> i <=
>>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>>
>>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>>> parts of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>>> resulting
>>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>>
>>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>>> target
>>>>>>>>>>>>> list,
>>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>>>> column in
>>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>>> Consider
>>>>>>>>>>>>> the
>>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>>
>>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>>
>>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of
>>>>>>>>>>>>> type
>>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>>>> that
>>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>>> failing
>>>>>>>>>>>>> case
>>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>>> ensure
>>>>>>>>>>>>> that
>>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>>>> separated
>>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jack
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>>> connect 'jdbc:derby:testdb;create=true';
>>>> create table TENKTUP1 (
>>>> unique1 int not null,
>>>> unique2 int not null,
>>>> two int,
>>>> four int,
>>>> ten int,
>>>> twenty int,
>>>> onePercent int,
>>>> tenPercent int,
>>>> twentyPercent int,
>>>> fiftyPercent int,
>>>> unique3 int,
>>>> evenOnePercent int,
>>>> oddOnePercent int,
>>>> stringu1 char(52) not null,
>>>> stringu2 char(52) not null,
>>>> string4 char(52)
>>>> );
>>>>
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Now , updating my local working directory, I could found what was happend at
Jack's site.
derbylang_report.txt at my site is uploaded next url.
http://www5.ocn.ne.jp/~tomohito/20050323/derbylang_report.txt
If anyone know, could you please give me some more information about next ?
>I think that there has been some sort of change in the way the Derby
>handles binding when there are correlation names.
> It must have been made about a week ago. It has affected some other stuff
> I am working on. I do not know who made the change, why, or exactly when.
The way I bind column in "resolveColumnReference" method was
based on original "bindOrderByColumn" method,
just replacing variable "correlationName" and "schemaName" to
return value of ColumnReference.getSourceTableName() method and
ColumnReference.getSchemaName() method.
Considering there were no problem before my patch,
I think there exist some changes in ColumnReference ...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, March 23, 2005 3:58 PM
Subject: Re: About improvement of DERBY-134
> You may have to do an svn update to bring in the lastest version of the
> source. I think that there has been some sort of change in the way the
> Derby handles binding when there are correlation names. Perhaps it is the
> combination of your changes and these other changes that cause the failure
> in wisconsin.sql.
>
> It must have been made about a week ago. It has affected some other stuff
> I am working on. I do not know who made the change, why, or exactly when.
>
> (Hopefully you will not have to do any merging).
>
> Perhaps the lang/orderby.sql tests need to be improved with some cases
> that use table correlation names in the order by clause. e.g.
>
> select * from (values (2),(1)) as t(x) orderby t.x
> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order by
> t2.c2,t1.id,t2.c3
>
> This is a test of functionality that existed before your changes. Test
> cases like these probably should have been in lang/orderby.sql before you
> started.
>
> Jack Klebanoff
>
> TomohitoNakayama wrote:
>
>> I have tried your small.sql and result was as next.
>>
>> --These are evidence for improvement of 134
>> ij> select * from test_number order by abs(value);
>> VALUE
>> -----------
>> 1
>> 2
>> 3
>>
>> 3 rows selected
>> ij> select * from test_number order by value * -1;
>> VALUE
>> -----------
>> 3
>> 2
>> 1
>>
>> 3 rows selected
>>
>> --This is what was written in small.sql
>> ij> create table TENKTUP1 (
>> unique1 int not null,
>> unique2 int not null,
>> two int,
>> four int,
>> ten int,
>> twenty int,
>> onePercent int,
>> tenPercent int,
>> twentyPercent int,
>> fiftyPercent int,
>> unique3 int,
>> evenOnePercent int,
>> oddOnePercent int,
>> stringu1 char(52) not null,
>> stringu2 char(52) not null,
>> string4 char(52)
>> );
>> 0 rows inserted/updated/deleted
>> ij> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> ij>
>>
>> Unfortunately, I could not found any ...
>>
>> And I attached derbylang_report.txt to this mail.
>> Can you find any clue in it ?
>> Are there any difference between yours ?
>>
>> If could. I want to yourr derbylang_report...
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Tuesday, March 22, 2005 7:33 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>>> writes a test report in suiteName_report.txt. This describes the
>>> environment, prints a counts of tests that passed and failed, and lists
>>> all the differences from expected in the failed tests. You can also find
>>> lists of passed and failed tests in suiteName_pass.txt and
>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>> derby.log files for the failed tests, but you have to dig deeper into
>>> the directories.
>>>
>>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>>> query
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> close c;
>>> failed to compile, but the test expected it to run. It worked before
>>> applying the patch, and I believe that it should work.
>>>
>>> I boiled the problem down to a small SQL file, which I have attached.
>>> That file should run without error under ij as long as database "testdb"
>>> does not exist when you start ij.
>>>
>>> I believe that the problem is with the updated bind method in
>>> OrderByNode. It does not seem to be able to handle correlation names
>>> from the FROM list. In the example that failed "t" is not the name of an
>>> actual table, but a correlation name used to name the "(values 1)"
>>> virtual table.
>>>
>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>> expression.bindExcpression and then eliminating most of the code in
>>> resolveColumnReference. However this does not work either. Then the
>>> statement
>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>> (from the lang/orderby.sql test) fails.
>>>
>>> I will work on this some more. Perhaps you can continue looking at it
>>> also.
>>>
>>> Jack
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> I have tried derbylang test suite , but could not found error which
>>>> was reported .
>>>>
>>>> What I found was just difference around "lang/floattypes.sql".
>>>> I 'm not sure this is error or not yet.
>>>>
>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>> ====================
>>>> -- Values clause is a single-row result set, so should not cause
>>>> optimizer
>>>> -- to require sort.
>>>>
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> close c;
>>>>
>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>
>>>> commit;
>>>>
>>>> -- Try with a join on unique column and order on non-unique column
>>>> ===================
>>>> I couldn't find difference between what in your mail.
>>>>
>>>>
>>>>
>>>> Next is svn-status of my wisconsin.sql.
>>>> ===================
>>>> $ svn status -v wisconsin.sql
>>>> 157254 122528 djd wisconsin.sql
>>>> ===================
>>>>
>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Thank you for your checking.
>>>>>
>>>>> I did'nt know way to test whole sqls.
>>>>> Sorry for insufficient test.
>>>>>
>>>>> Now I will try whole test.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>>>> failed. The problem output was:
>>>>>>
>>>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>>>> optimizer
>>>>>> -- to require sort.
>>>>>> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which
>>>>>> it
>>>>>> appears.
>>>>>>
>>>>>> This error is incorrect.
>>>>>>
>>>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>
>>>>>> You should probably run at least the derbylang test suite before
>>>>>> submitting a patch for ORDER BY.
>>>>>>
>>>>>> To do this, change into an empty directory and run
>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>>>> suite takes 5 or 6 hours.
>>>>>>
>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>> directory and run
>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>> lang/wisconsin.sql
>>>>>>
>>>>>> Jack Klebanoff
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> Thank for your checking.
>>>>>>> I have solved the 2 problems.
>>>>>>> Attached file is new patch.
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>> <kl...@sbcglobal.net>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>>>> serious and the other minor.
>>>>>>>>
>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>>> problem
>>>>>>>> is in the
>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>
>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>> cm)
>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>> ClassCastException
>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>
>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>>>> ValueNode. I think that
>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>> cm),
>>>>>>>> cm)
>>>>>>>> works.
>>>>>>>>
>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>> Object
>>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>>
>>>>>>>> Jack Klebanoff
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>
>>>>>>>>> Would you please review it ?
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>
>>>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>>>> on an
>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>> developpers
>>>>>>>>>> have
>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>> working on
>>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>>> pretty
>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>
>>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>>> further.
>>>>>>>>>>
>>>>>>>>>> Satheesh
>>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>
>>>>>>>>>>> About 1:
>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>> I will try.
>>>>>>>>>>>
>>>>>>>>>>> About 2:
>>>>>>>>>>> Uh oh.
>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>> orderby.sql
>>>>>>>>>>> was needed.....
>>>>>>>>>>>
>>>>>>>>>>> About 3:
>>>>>>>>>>> I see.
>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>
>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>
>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>>>> fixed
>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>> patch.
>>>>>>>>>>>> It is
>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>> non-reserved
>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>>>> to add
>>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>>> If we
>>>>>>>>>>>> need
>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>>> of them
>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>
>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>> sort
>>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>>> the
>>>>>>>>>>>> parser
>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>> ordering. I
>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>> class
>>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>>
>>>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>>>> of an
>>>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>>>> as the
>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>>>> in the
>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>> alternative the
>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>> given
>>>>>>>>>>>> by an
>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>> determine
>>>>>>>>>>>> whether the sort key expression is an integer constant, and if
>>>>>>>>>>>> so
>>>>>>>>>>>> treat
>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>
>>>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>>>> integer
>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by
>>>>>>>>>>>> the
>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>>>> ASC"
>>>>>>>>>>>> and
>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>>>> treated
>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>> position
>>>>>>>>>>>> then
>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>>>> result
>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch
>>>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>
>>>>>>>>>>>> The new code is
>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>
>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>
>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>> i ++){
>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>> break;
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>> indexing. The
>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>>>> = 1;
>>>>>>>>>>>> i <=
>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>
>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>> parts of
>>>>>>>>>>>> the
>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>> resulting
>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>
>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>> target
>>>>>>>>>>>> list,
>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>>> column in
>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>> Consider
>>>>>>>>>>>> the
>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>
>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>
>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>>> that
>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>
>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>> failing
>>>>>>>>>>>> case
>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>> ensure
>>>>>>>>>>>> that
>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>>> separated
>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>
>>>>>>>>>>>> Jack
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>> connect 'jdbc:derby:testdb;create=true';
>>> create table TENKTUP1 (
>>> unique1 int not null,
>>> unique2 int not null,
>>> two int,
>>> four int,
>>> ten int,
>>> twenty int,
>>> onePercent int,
>>> tenPercent int,
>>> twentyPercent int,
>>> fiftyPercent int,
>>> unique3 int,
>>> evenOnePercent int,
>>> oddOnePercent int,
>>> stringu1 char(52) not null,
>>> stringu2 char(52) not null,
>>> string4 char(52)
>>> );
>>>
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>>
>>>
>>
>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Thanks Jack.
I have just begun to suspect logical conflict too.
Difference between numberes of test suggest it.
I will try svn update command.
And test again.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, March 23, 2005 3:58 PM
Subject: Re: About improvement of DERBY-134
> You may have to do an svn update to bring in the lastest version of the
> source. I think that there has been some sort of change in the way the
> Derby handles binding when there are correlation names. Perhaps it is the
> combination of your changes and these other changes that cause the failure
> in wisconsin.sql.
>
> It must have been made about a week ago. It has affected some other stuff
> I am working on. I do not know who made the change, why, or exactly when.
>
> (Hopefully you will not have to do any merging).
>
> Perhaps the lang/orderby.sql tests need to be improved with some cases
> that use table correlation names in the order by clause. e.g.
>
> select * from (values (2),(1)) as t(x) orderby t.x
> select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order by
> t2.c2,t1.id,t2.c3
>
> This is a test of functionality that existed before your changes. Test
> cases like these probably should have been in lang/orderby.sql before you
> started.
>
> Jack Klebanoff
>
> TomohitoNakayama wrote:
>
>> I have tried your small.sql and result was as next.
>>
>> --These are evidence for improvement of 134
>> ij> select * from test_number order by abs(value);
>> VALUE
>> -----------
>> 1
>> 2
>> 3
>>
>> 3 rows selected
>> ij> select * from test_number order by value * -1;
>> VALUE
>> -----------
>> 3
>> 2
>> 1
>>
>> 3 rows selected
>>
>> --This is what was written in small.sql
>> ij> create table TENKTUP1 (
>> unique1 int not null,
>> unique2 int not null,
>> two int,
>> four int,
>> ten int,
>> twenty int,
>> onePercent int,
>> tenPercent int,
>> twentyPercent int,
>> fiftyPercent int,
>> unique3 int,
>> evenOnePercent int,
>> oddOnePercent int,
>> stringu1 char(52) not null,
>> stringu2 char(52) not null,
>> string4 char(52)
>> );
>> 0 rows inserted/updated/deleted
>> ij> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> ij>
>>
>> Unfortunately, I could not found any ...
>>
>> And I attached derbylang_report.txt to this mail.
>> Can you find any clue in it ?
>> Are there any difference between yours ?
>>
>> If could. I want to yourr derbylang_report...
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Tuesday, March 22, 2005 7:33 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>>> writes a test report in suiteName_report.txt. This describes the
>>> environment, prints a counts of tests that passed and failed, and lists
>>> all the differences from expected in the failed tests. You can also find
>>> lists of passed and failed tests in suiteName_pass.txt and
>>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>>> derby.log files for the failed tests, but you have to dig deeper into
>>> the directories.
>>>
>>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>>> query
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> close c;
>>> failed to compile, but the test expected it to run. It worked before
>>> applying the patch, and I believe that it should work.
>>>
>>> I boiled the problem down to a small SQL file, which I have attached.
>>> That file should run without error under ij as long as database "testdb"
>>> does not exist when you start ij.
>>>
>>> I believe that the problem is with the updated bind method in
>>> OrderByNode. It does not seem to be able to handle correlation names
>>> from the FROM list. In the example that failed "t" is not the name of an
>>> actual table, but a correlation name used to name the "(values 1)"
>>> virtual table.
>>>
>>> I tried changing OrderByColumn.bindOrderByColumn to call
>>> expression.bindExcpression and then eliminating most of the code in
>>> resolveColumnReference. However this does not work either. Then the
>>> statement
>>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>>> (from the lang/orderby.sql test) fails.
>>>
>>> I will work on this some more. Perhaps you can continue looking at it
>>> also.
>>>
>>> Jack
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> I have tried derbylang test suite , but could not found error which
>>>> was reported .
>>>>
>>>> What I found was just difference around "lang/floattypes.sql".
>>>> I 'm not sure this is error or not yet.
>>>>
>>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>>> ====================
>>>> -- Values clause is a single-row result set, so should not cause
>>>> optimizer
>>>> -- to require sort.
>>>>
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> close c;
>>>>
>>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>>
>>>> commit;
>>>>
>>>> -- Try with a join on unique column and order on non-unique column
>>>> ===================
>>>> I couldn't find difference between what in your mail.
>>>>
>>>>
>>>>
>>>> Next is svn-status of my wisconsin.sql.
>>>> ===================
>>>> $ svn status -v wisconsin.sql
>>>> 157254 122528 djd wisconsin.sql
>>>> ===================
>>>>
>>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Saturday, March 19, 2005 3:42 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Thank you for your checking.
>>>>>
>>>>> I did'nt know way to test whole sqls.
>>>>> Sorry for insufficient test.
>>>>>
>>>>> Now I will try whole test.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>>>> failed. The problem output was:
>>>>>>
>>>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>>>> optimizer
>>>>>> -- to require sort.
>>>>>> get cursor c as
>>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>>> where TENKTUP1.unique1 = t.x
>>>>>> order by TENKTUP1.unique1, t.x';
>>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which
>>>>>> it
>>>>>> appears.
>>>>>>
>>>>>> This error is incorrect.
>>>>>>
>>>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>>
>>>>>> You should probably run at least the derbylang test suite before
>>>>>> submitting a patch for ORDER BY.
>>>>>>
>>>>>> To do this, change into an empty directory and run
>>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>>>> suite takes 5 or 6 hours.
>>>>>>
>>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>>> directory and run
>>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>>> lang/wisconsin.sql
>>>>>>
>>>>>> Jack Klebanoff
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> Thank for your checking.
>>>>>>> I have solved the 2 problems.
>>>>>>> Attached file is new patch.
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>> <kl...@sbcglobal.net>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>>>> serious and the other minor.
>>>>>>>>
>>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>>> problem
>>>>>>>> is in the
>>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>>
>>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>> cm)
>>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>>> ClassCastException
>>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>>
>>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>>>> ValueNode. I think that
>>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>>> cm),
>>>>>>>> cm)
>>>>>>>> works.
>>>>>>>>
>>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>>> Object
>>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>>
>>>>>>>> Jack Klebanoff
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>>> I'm not sure test is enough.
>>>>>>>>>
>>>>>>>>> Would you please review it ?
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>>> <sa...@sourcery.org>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>>
>>>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>>>> on an
>>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>>> developpers
>>>>>>>>>> have
>>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>>> working on
>>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>>> pretty
>>>>>>>>>> close to addressing all issues.
>>>>>>>>>>
>>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>>> further.
>>>>>>>>>>
>>>>>>>>>> Satheesh
>>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>>
>>>>>>>>>>> About 1:
>>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>>> I will try.
>>>>>>>>>>>
>>>>>>>>>>> About 2:
>>>>>>>>>>> Uh oh.
>>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>>> ResultColumnList ....
>>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>>> orderby.sql
>>>>>>>>>>> was needed.....
>>>>>>>>>>>
>>>>>>>>>>> About 3:
>>>>>>>>>>> I see.
>>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>>
>>>>>>>>>>> I will continue this issue.
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>> You
>>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>>> order
>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>>
>>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>>>> fixed
>>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>>> patch.
>>>>>>>>>>>> It is
>>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>>
>>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>>> non-reserved
>>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>>>> to add
>>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>>> If we
>>>>>>>>>>>> need
>>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>>> of them
>>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>>
>>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>>> ORDER BY
>>>>>>>>>>>> sort
>>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>>> the
>>>>>>>>>>>> parser
>>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>>> ordering. I
>>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>>> OrderByColumn
>>>>>>>>>>>> class
>>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>>
>>>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>>>> of an
>>>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>>>> as the
>>>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>>>> in the
>>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>>> alternative the
>>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>>> given
>>>>>>>>>>>> by an
>>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>>> determine
>>>>>>>>>>>> whether the sort key expression is an integer constant, and if
>>>>>>>>>>>> so
>>>>>>>>>>>> treat
>>>>>>>>>>>> it as a column position.
>>>>>>>>>>>>
>>>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>>>> integer
>>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by
>>>>>>>>>>>> the
>>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>>>> ASC"
>>>>>>>>>>>> and
>>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>>>> treated
>>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>>> position
>>>>>>>>>>>> then
>>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>>>> result
>>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>>
>>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch
>>>>>>>>>>>> to
>>>>>>>>>>>> the
>>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>>
>>>>>>>>>>>> The new code is
>>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>>
>>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>>> int i = 0;
>>>>>>>>>>>>
>>>>>>>>>>>> for(i = 0;
>>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>>> i ++){
>>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>>> if(col != null &&
>>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>>> break;
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>>> indexing. The
>>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>>>> = 1;
>>>>>>>>>>>> i <=
>>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>>
>>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>>> parts of
>>>>>>>>>>>> the
>>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>>> resulting
>>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>>
>>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>>> target
>>>>>>>>>>>> list,
>>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>>> column in
>>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>>> Consider
>>>>>>>>>>>> the
>>>>>>>>>>>> following SQL:
>>>>>>>>>>>>
>>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>>
>>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>>>> 'BLOB'
>>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>>> INTERSECT,
>>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>>> that
>>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>>
>>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>>> failing
>>>>>>>>>>>> case
>>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>>> ensure
>>>>>>>>>>>> that
>>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>>> separated
>>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>>
>>>>>>>>>>>> Jack
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>> connect 'jdbc:derby:testdb;create=true';
>>> create table TENKTUP1 (
>>> unique1 int not null,
>>> unique2 int not null,
>>> two int,
>>> four int,
>>> ten int,
>>> twenty int,
>>> onePercent int,
>>> tenPercent int,
>>> twentyPercent int,
>>> fiftyPercent int,
>>> unique3 int,
>>> evenOnePercent int,
>>> oddOnePercent int,
>>> stringu1 char(52) not null,
>>> stringu2 char(52) not null,
>>> string4 char(52)
>>> );
>>>
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>>
>>>
>>
>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
You may have to do an svn update to bring in the lastest version of the
source. I think that there has been some sort of change in the way the
Derby handles binding when there are correlation names. Perhaps it is
the combination of your changes and these other changes that cause the
failure in wisconsin.sql.
It must have been made about a week ago. It has affected some other
stuff I am working on. I do not know who made the change, why, or
exactly when.
(Hopefully you will not have to do any merging).
Perhaps the lang/orderby.sql tests need to be improved with some cases
that use table correlation names in the order by clause. e.g.
select * from (values (2),(1)) as t(x) orderby t.x
select t1.id,t2.c3 from ta as t1 join tb as t2 on t1.id = t2.id order by
t2.c2,t1.id,t2.c3
This is a test of functionality that existed before your changes. Test
cases like these probably should have been in lang/orderby.sql before
you started.
Jack Klebanoff
TomohitoNakayama wrote:
> I have tried your small.sql and result was as next.
>
> --These are evidence for improvement of 134
> ij> select * from test_number order by abs(value);
> VALUE
> -----------
> 1
> 2
> 3
>
> 3 rows selected
> ij> select * from test_number order by value * -1;
> VALUE
> -----------
> 3
> 2
> 1
>
> 3 rows selected
>
> --This is what was written in small.sql
> ij> create table TENKTUP1 (
> unique1 int not null,
> unique2 int not null,
> two int,
> four int,
> ten int,
> twenty int,
> onePercent int,
> tenPercent int,
> twentyPercent int,
> fiftyPercent int,
> unique3 int,
> evenOnePercent int,
> oddOnePercent int,
> stringu1 char(52) not null,
> stringu2 char(52) not null,
> string4 char(52)
> );
> 0 rows inserted/updated/deleted
> ij> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> ij>
>
> Unfortunately, I could not found any ...
>
> And I attached derbylang_report.txt to this mail.
> Can you find any clue in it ?
> Are there any difference between yours ?
>
> If could. I want to yourr derbylang_report...
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Jack Klebanoff"
> <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Tuesday, March 22, 2005 7:33 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>> writes a test report in suiteName_report.txt. This describes the
>> environment, prints a counts of tests that passed and failed, and lists
>> all the differences from expected in the failed tests. You can also find
>> lists of passed and failed tests in suiteName_pass.txt and
>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>> derby.log files for the failed tests, but you have to dig deeper into
>> the directories.
>>
>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>> query
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> close c;
>> failed to compile, but the test expected it to run. It worked before
>> applying the patch, and I believe that it should work.
>>
>> I boiled the problem down to a small SQL file, which I have attached.
>> That file should run without error under ij as long as database "testdb"
>> does not exist when you start ij.
>>
>> I believe that the problem is with the updated bind method in
>> OrderByNode. It does not seem to be able to handle correlation names
>> from the FROM list. In the example that failed "t" is not the name of an
>> actual table, but a correlation name used to name the "(values 1)"
>> virtual table.
>>
>> I tried changing OrderByColumn.bindOrderByColumn to call
>> expression.bindExcpression and then eliminating most of the code in
>> resolveColumnReference. However this does not work either. Then the
>> statement
>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>> (from the lang/orderby.sql test) fails.
>>
>> I will work on this some more. Perhaps you can continue looking at it
>> also.
>>
>> Jack
>>
>> TomohitoNakayama wrote:
>>
>>> I have tried derbylang test suite , but could not found error which
>>> was reported .
>>>
>>> What I found was just difference around "lang/floattypes.sql".
>>> I 'm not sure this is error or not yet.
>>>
>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>> ====================
>>> -- Values clause is a single-row result set, so should not cause
>>> optimizer
>>> -- to require sort.
>>>
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> close c;
>>>
>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>
>>> commit;
>>>
>>> -- Try with a join on unique column and order on non-unique column
>>> ===================
>>> I couldn't find difference between what in your mail.
>>>
>>>
>>>
>>> Next is svn-status of my wisconsin.sql.
>>> ===================
>>> $ svn status -v wisconsin.sql
>>> 157254 122528 djd wisconsin.sql
>>> ===================
>>>
>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, March 19, 2005 3:42 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Thank you for your checking.
>>>>
>>>> I did'nt know way to test whole sqls.
>>>> Sorry for insufficient test.
>>>>
>>>> Now I will try whole test.
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>>> failed. The problem output was:
>>>>>
>>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>>> optimizer
>>>>> -- to require sort.
>>>>> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in
>>>>> which it
>>>>> appears.
>>>>>
>>>>> This error is incorrect.
>>>>>
>>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>
>>>>> You should probably run at least the derbylang test suite before
>>>>> submitting a patch for ORDER BY.
>>>>>
>>>>> To do this, change into an empty directory and run
>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>>> suite takes 5 or 6 hours.
>>>>>
>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>> directory and run
>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>> lang/wisconsin.sql
>>>>>
>>>>> Jack Klebanoff
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> Thank for your checking.
>>>>>> I have solved the 2 problems.
>>>>>> Attached file is new patch.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>> <kl...@sbcglobal.net>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>>> serious and the other minor.
>>>>>>>
>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>> problem
>>>>>>> is in the
>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>
>>>>>>>
>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>> cm)
>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>> ClassCastException
>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>
>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>>> ValueNode. I think that
>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>> cm),
>>>>>>> cm)
>>>>>>> works.
>>>>>>>
>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>> Object
>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>
>>>>>>> Jack Klebanoff
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>> I'm not sure test is enough.
>>>>>>>>
>>>>>>>> Would you please review it ?
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>> <sa...@sourcery.org>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>
>>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>>> on an
>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>> developpers
>>>>>>>>> have
>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>> working on
>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>> pretty
>>>>>>>>> close to addressing all issues.
>>>>>>>>>
>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>> further.
>>>>>>>>>
>>>>>>>>> Satheesh
>>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>
>>>>>>>>>> About 1:
>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>> I will try.
>>>>>>>>>>
>>>>>>>>>> About 2:
>>>>>>>>>> Uh oh.
>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>> ResultColumnList ....
>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>> orderby.sql
>>>>>>>>>> was needed.....
>>>>>>>>>>
>>>>>>>>>> About 3:
>>>>>>>>>> I see.
>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>
>>>>>>>>>> I will continue this issue.
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>>
>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>
>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>
>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the
>>>>>>>>>>>>>> way the
>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>>> both
>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>> You
>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>> order
>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>
>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>>> fixed
>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>> patch.
>>>>>>>>>>> It is
>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>
>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>> non-reserved
>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>>> to add
>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>> If we
>>>>>>>>>>> need
>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>> of them
>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>
>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>> ORDER BY
>>>>>>>>>>> sort
>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>> the
>>>>>>>>>>> parser
>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>> ordering. I
>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>> OrderByColumn
>>>>>>>>>>> class
>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>
>>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>>> of an
>>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>>> as the
>>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>>> in the
>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>> alternative the
>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>> given
>>>>>>>>>>> by an
>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>> determine
>>>>>>>>>>> whether the sort key expression is an integer constant, and
>>>>>>>>>>> if so
>>>>>>>>>>> treat
>>>>>>>>>>> it as a column position.
>>>>>>>>>>>
>>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>>> integer
>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows
>>>>>>>>>>> by the
>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>>> ASC"
>>>>>>>>>>> and
>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>>> treated
>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>> position
>>>>>>>>>>> then
>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>>> result
>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>
>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the
>>>>>>>>>>> patch to
>>>>>>>>>>> the
>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>
>>>>>>>>>>> The new code is
>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>
>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>> int i = 0;
>>>>>>>>>>>
>>>>>>>>>>> for(i = 0;
>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>> i ++){
>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>> if(col != null &&
>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>> break;
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>> indexing. The
>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>>> = 1;
>>>>>>>>>>> i <=
>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>
>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>> parts of
>>>>>>>>>>> the
>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>> resulting
>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>
>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>> target
>>>>>>>>>>> list,
>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>> column in
>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>> Consider
>>>>>>>>>>> the
>>>>>>>>>>> following SQL:
>>>>>>>>>>>
>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>
>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>>> 'BLOB'
>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>> INTERSECT,
>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>> that
>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>
>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>> failing
>>>>>>>>>>> case
>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>> ensure
>>>>>>>>>>> that
>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>> separated
>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>
>>>>>>>>>>> Jack
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>
>> connect 'jdbc:derby:testdb;create=true';
>> create table TENKTUP1 (
>> unique1 int not null,
>> unique2 int not null,
>> two int,
>> four int,
>> ten int,
>> twenty int,
>> onePercent int,
>> tenPercent int,
>> twentyPercent int,
>> fiftyPercent int,
>> unique3 int,
>> evenOnePercent int,
>> oddOnePercent int,
>> stringu1 char(52) not null,
>> stringu2 char(52) not null,
>> string4 char(52)
>> );
>>
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>>
>>
>
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
I have tried your small.sql and result was as next.
--These are evidence for improvement of 134
ij> select * from test_number order by abs(value);
VALUE
-----------
1
2
3
3 rows selected
ij> select * from test_number order by value * -1;
VALUE
-----------
3
2
1
3 rows selected
--This is what was written in small.sql
ij> create table TENKTUP1 (
unique1 int not null,
unique2 int not null,
two int,
four int,
ten int,
twenty int,
onePercent int,
tenPercent int,
twentyPercent int,
fiftyPercent int,
unique3 int,
evenOnePercent int,
oddOnePercent int,
stringu1 char(52) not null,
stringu2 char(52) not null,
string4 char(52)
);
0 rows inserted/updated/deleted
ij> get cursor c as
'select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x';
ij>
Unfortunately, I could not found any ...
And I attached derbylang_report.txt to this mail.
Can you find any clue in it ?
Are there any difference between yours ?
If could. I want to yourr derbylang_report...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, March 22, 2005 7:33 AM
Subject: Re: About improvement of DERBY-134
> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
> writes a test report in suiteName_report.txt. This describes the
> environment, prints a counts of tests that passed and failed, and lists
> all the differences from expected in the failed tests. You can also find
> lists of passed and failed tests in suiteName_pass.txt and
> suiteName_fail.txt. You can also find outputs, diffs, databases, and
> derby.log files for the failed tests, but you have to dig deeper into
> the directories.
>
> When I ran the lang/wisconsin.sql test with your patch it failed. The
> query
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> close c;
> failed to compile, but the test expected it to run. It worked before
> applying the patch, and I believe that it should work.
>
> I boiled the problem down to a small SQL file, which I have attached.
> That file should run without error under ij as long as database "testdb"
> does not exist when you start ij.
>
> I believe that the problem is with the updated bind method in
> OrderByNode. It does not seem to be able to handle correlation names
> from the FROM list. In the example that failed "t" is not the name of an
> actual table, but a correlation name used to name the "(values 1)"
> virtual table.
>
> I tried changing OrderByColumn.bindOrderByColumn to call
> expression.bindExcpression and then eliminating most of the code in
> resolveColumnReference. However this does not work either. Then the
> statement
> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
> (from the lang/orderby.sql test) fails.
>
> I will work on this some more. Perhaps you can continue looking at it
> also.
>
> Jack
>
> TomohitoNakayama wrote:
>
>> I have tried derbylang test suite , but could not found error which
>> was reported .
>>
>> What I found was just difference around "lang/floattypes.sql".
>> I 'm not sure this is error or not yet.
>>
>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>> ====================
>> -- Values clause is a single-row result set, so should not cause
>> optimizer
>> -- to require sort.
>>
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> close c;
>>
>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>
>> commit;
>>
>> -- Try with a join on unique column and order on non-unique column
>> ===================
>> I couldn't find difference between what in your mail.
>>
>>
>>
>> Next is svn-status of my wisconsin.sql.
>> ===================
>> $ svn status -v wisconsin.sql
>> 157254 122528 djd wisconsin.sql
>> ===================
>>
>> Is this caused by versioning problem of wisconsin.sql ...?
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, March 19, 2005 3:42 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Thank you for your checking.
>>>
>>> I did'nt know way to test whole sqls.
>>> Sorry for insufficient test.
>>>
>>> Now I will try whole test.
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, March 19, 2005 9:04 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>> failed. The problem output was:
>>>>
>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>> optimizer
>>>> -- to require sort.
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which it
>>>> appears.
>>>>
>>>> This error is incorrect.
>>>>
>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>> expressions. I don't have time to look more deeply into it now.
>>>>
>>>> You should probably run at least the derbylang test suite before
>>>> submitting a patch for ORDER BY.
>>>>
>>>> To do this, change into an empty directory and run
>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>> suite takes 5 or 6 hours.
>>>>
>>>> In order to run just the wisconsin.sql test change into an empty
>>>> directory and run
>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>> lang/wisconsin.sql
>>>>
>>>> Jack Klebanoff
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> Thank for your checking.
>>>>> I have solved the 2 problems.
>>>>> Attached file is new patch.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>> serious and the other minor.
>>>>>>
>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>> problem
>>>>>> is in the
>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>
>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>> cm)
>>>>>> This used to work. Now OrderByColumn.init throws a ClassCastException
>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>
>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>> ValueNode. I think that
>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>> cm),
>>>>>> cm)
>>>>>> works.
>>>>>>
>>>>>> The minor problem is that the javadoc for OrderByColumn.init( Object
>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>
>>>>>> Jack Klebanoff
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>> I'm not sure test is enough.
>>>>>>>
>>>>>>> Would you please review it ?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>> <sa...@sourcery.org>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>
>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>> on an
>>>>>>>> important enhancement that not only yourself but other developpers
>>>>>>>> have
>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>> working on
>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>> pretty
>>>>>>>> close to addressing all issues.
>>>>>>>>
>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>> further.
>>>>>>>>
>>>>>>>> Satheesh
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>
>>>>>>>>> About 1:
>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>> A little challenging but worth for it.
>>>>>>>>> I will try.
>>>>>>>>>
>>>>>>>>> About 2:
>>>>>>>>> Uh oh.
>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>> ResultColumnList ....
>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>> orderby.sql
>>>>>>>>> was needed.....
>>>>>>>>>
>>>>>>>>> About 3:
>>>>>>>>> I see.
>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>
>>>>>>>>> I will continue this issue.
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>
>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Sorry.
>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>
>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>
>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>> done.
>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>> are:
>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>>>>>> patch
>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>> both
>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>> select i
>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>>>>>> You
>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>> part of
>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>> order
>>>>>>>>>>>>> clause.
>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>>
>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>> fixed
>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>>>>>> It is
>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>
>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>> non-reserved
>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>> to add
>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>> If we
>>>>>>>>>> need
>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>> of them
>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>
>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>> ORDER BY
>>>>>>>>>> sort
>>>>>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>>>>>> parser
>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>> ordering. I
>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>> OrderByColumn
>>>>>>>>>> class
>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>
>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>> of an
>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>> as the
>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>> in the
>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>> alternative the
>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>>>>>> by an
>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>> determine
>>>>>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>>>>>> treat
>>>>>>>>>> it as a column position.
>>>>>>>>>>
>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>> integer
>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>> ASC"
>>>>>>>>>> and
>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>> treated
>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>> position
>>>>>>>>>> then
>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>> result
>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>
>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>>>>>> the
>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>
>>>>>>>>>> The new code is
>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>
>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>> int i = 0;
>>>>>>>>>>
>>>>>>>>>> for(i = 0;
>>>>>>>>>> i < targetCols.size();
>>>>>>>>>> i ++){
>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>> if(col != null &&
>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>> break;
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>> indexing. The
>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>> = 1;
>>>>>>>>>> i <=
>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>
>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>> parts of
>>>>>>>>>> the
>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>> resulting
>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>
>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>> target
>>>>>>>>>> list,
>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>> column in
>>>>>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>>>>>> the
>>>>>>>>>> following SQL:
>>>>>>>>>>
>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>
>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>> 'BLOB'
>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>> INTERSECT,
>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>> that
>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>
>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>> failing
>>>>>>>>>> case
>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>>>>>> that
>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>> separated
>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>
>>>>>>>>>> Jack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
>
--------------------------------------------------------------------------------
> connect 'jdbc:derby:testdb;create=true';
> create table TENKTUP1 (
> unique1 int not null,
> unique2 int not null,
> two int,
> four int,
> ten int,
> twenty int,
> onePercent int,
> tenPercent int,
> twentyPercent int,
> fiftyPercent int,
> unique3 int,
> evenOnePercent int,
> oddOnePercent int,
> stringu1 char(52) not null,
> stringu2 char(52) not null,
> string4 char(52)
> );
>
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
>
>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
I tried re-applying your patch, rebuilding, and re-running the derbylang
suite. The result was the same: the lang/wisconsin.sql test failed.
Interestingly my derbylang suite ran 1 more test than was reported in
your derbylang_report.txt at
http://www5.ocn.ne.jp/~tomohito/derbylang_report.txt. I do not know why
it worked for you. The stack trace from the derby.log file was:
Statement is: select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x
ERROR 42X10: 'T' is not an exposed table name in the scope in which it
appears.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
at
org.apache.derby.impl.sql.compile.OrderByColumn.resolveColumnReference(OrderByColumn.java:312)
at
org.apache.derby.impl.sql.compile.OrderByColumn.bindOrderByColumn(OrderByColumn.java:147)
at
org.apache.derby.impl.sql.compile.OrderByList.bindOrderByColumns(OrderByList.java:153)
at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java:255)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:332)
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:688)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:501)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java:130)
at org.apache.derby.impl.tools.ij.ij.GetCursorStatement(ij.java:1102)
at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:550)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:289)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:209)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:175)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
at org.apache.derby.tools.ij.main(ij.java:60)
I have attached my derbylang_report.txt file.
Jack
TomohitoNakayama wrote:
> I have tried your small.sql and result was as next.
>
> --These are evidence for improvement of 134
> ij> select * from test_number order by abs(value);
> VALUE
> -----------
> 1
> 2
> 3
>
> 3 rows selected
> ij> select * from test_number order by value * -1;
> VALUE
> -----------
> 3
> 2
> 1
>
> 3 rows selected
>
> --This is what was written in small.sql
> ij> create table TENKTUP1 (
> unique1 int not null,
> unique2 int not null,
> two int,
> four int,
> ten int,
> twenty int,
> onePercent int,
> tenPercent int,
> twentyPercent int,
> fiftyPercent int,
> unique3 int,
> evenOnePercent int,
> oddOnePercent int,
> stringu1 char(52) not null,
> stringu2 char(52) not null,
> string4 char(52)
> );
> 0 rows inserted/updated/deleted
> ij> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> ij>
>
> Unfortunately, I could not found any ...
>
> And I uploaded derbylang_report.txt to next url.
>
> http://www5.ocn.ne.jp/~tomohito/derbylang_report.txt
>
> Can you find any clue in it ?
> Are there any difference between yours ?
>
> If could. I want to yourr derbylang_report...
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Jack Klebanoff"
> <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Tuesday, March 22, 2005 7:33 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
>> writes a test report in suiteName_report.txt. This describes the
>> environment, prints a counts of tests that passed and failed, and lists
>> all the differences from expected in the failed tests. You can also find
>> lists of passed and failed tests in suiteName_pass.txt and
>> suiteName_fail.txt. You can also find outputs, diffs, databases, and
>> derby.log files for the failed tests, but you have to dig deeper into
>> the directories.
>>
>> When I ran the lang/wisconsin.sql test with your patch it failed. The
>> query
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> close c;
>> failed to compile, but the test expected it to run. It worked before
>> applying the patch, and I believe that it should work.
>>
>> I boiled the problem down to a small SQL file, which I have attached.
>> That file should run without error under ij as long as database "testdb"
>> does not exist when you start ij.
>>
>> I believe that the problem is with the updated bind method in
>> OrderByNode. It does not seem to be able to handle correlation names
>> from the FROM list. In the example that failed "t" is not the name of an
>> actual table, but a correlation name used to name the "(values 1)"
>> virtual table.
>>
>> I tried changing OrderByColumn.bindOrderByColumn to call
>> expression.bindExcpression and then eliminating most of the code in
>> resolveColumnReference. However this does not work either. Then the
>> statement
>> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
>> (from the lang/orderby.sql test) fails.
>>
>> I will work on this some more. Perhaps you can continue looking at it
>> also.
>>
>> Jack
>>
>> TomohitoNakayama wrote:
>>
>>> I have tried derbylang test suite , but could not found error which
>>> was reported .
>>>
>>> What I found was just difference around "lang/floattypes.sql".
>>> I 'm not sure this is error or not yet.
>>>
>>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>>> ====================
>>> -- Values clause is a single-row result set, so should not cause
>>> optimizer
>>> -- to require sort.
>>>
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> close c;
>>>
>>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>>
>>> commit;
>>>
>>> -- Try with a join on unique column and order on non-unique column
>>> ===================
>>> I couldn't find difference between what in your mail.
>>>
>>>
>>>
>>> Next is svn-status of my wisconsin.sql.
>>> ===================
>>> $ svn status -v wisconsin.sql
>>> 157254 122528 djd wisconsin.sql
>>> ===================
>>>
>>> Is this caused by versioning problem of wisconsin.sql ...?
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, March 19, 2005 3:42 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Thank you for your checking.
>>>>
>>>> I did'nt know way to test whole sqls.
>>>> Sorry for insufficient test.
>>>>
>>>> Now I will try whole test.
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Saturday, March 19, 2005 9:04 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>>> failed. The problem output was:
>>>>>
>>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>>> optimizer
>>>>> -- to require sort.
>>>>> get cursor c as
>>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>>> where TENKTUP1.unique1 = t.x
>>>>> order by TENKTUP1.unique1, t.x';
>>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in
>>>>> which it
>>>>> appears.
>>>>>
>>>>> This error is incorrect.
>>>>>
>>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>>> expressions. I don't have time to look more deeply into it now.
>>>>>
>>>>> You should probably run at least the derbylang test suite before
>>>>> submitting a patch for ORDER BY.
>>>>>
>>>>> To do this, change into an empty directory and run
>>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>>> suite takes 5 or 6 hours.
>>>>>
>>>>> In order to run just the wisconsin.sql test change into an empty
>>>>> directory and run
>>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>>> lang/wisconsin.sql
>>>>>
>>>>> Jack Klebanoff
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> Thank for your checking.
>>>>>> I have solved the 2 problems.
>>>>>> Attached file is new patch.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>> <kl...@sbcglobal.net>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>>> serious and the other minor.
>>>>>>>
>>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>>> problem
>>>>>>> is in the
>>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>>
>>>>>>>
>>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>> cm)
>>>>>>> This used to work. Now OrderByColumn.init throws a
>>>>>>> ClassCastException
>>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>>
>>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>>> ValueNode. I think that
>>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>>> cm),
>>>>>>> cm)
>>>>>>> works.
>>>>>>>
>>>>>>> The minor problem is that the javadoc for OrderByColumn.init(
>>>>>>> Object
>>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>>
>>>>>>> Jack Klebanoff
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>>> I'm not sure test is enough.
>>>>>>>>
>>>>>>>> Would you please review it ?
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>>> <sa...@sourcery.org>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>>
>>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>>> on an
>>>>>>>>> important enhancement that not only yourself but other
>>>>>>>>> developpers
>>>>>>>>> have
>>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>>> working on
>>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>>> pretty
>>>>>>>>> close to addressing all issues.
>>>>>>>>>
>>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>>> further.
>>>>>>>>>
>>>>>>>>> Satheesh
>>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>>
>>>>>>>>>> About 1:
>>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>>> A little challenging but worth for it.
>>>>>>>>>> I will try.
>>>>>>>>>>
>>>>>>>>>> About 2:
>>>>>>>>>> Uh oh.
>>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>>> ResultColumnList ....
>>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>>> orderby.sql
>>>>>>>>>> was needed.....
>>>>>>>>>>
>>>>>>>>>> About 3:
>>>>>>>>>> I see.
>>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>>
>>>>>>>>>> I will continue this issue.
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>>
>>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>>
>>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry.
>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>
>>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>>> are:
>>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the
>>>>>>>>>>>>>> way the
>>>>>>>>>>>>>> patch
>>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>>> both
>>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>>> select i
>>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>>> Add more test cases and test outputs to show changed
>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>> You
>>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>>> order
>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Naka
>>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>>
>>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>>> fixed
>>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your
>>>>>>>>>>> patch.
>>>>>>>>>>> It is
>>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>>
>>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>>> non-reserved
>>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>>> to add
>>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>>> If we
>>>>>>>>>>> need
>>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>>> of them
>>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>>
>>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>>> ORDER BY
>>>>>>>>>>> sort
>>>>>>>>>>> key type. A column name is just one kind of <expression>. If
>>>>>>>>>>> the
>>>>>>>>>>> parser
>>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>>> ordering. I
>>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>>> OrderByColumn
>>>>>>>>>>> class
>>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>>
>>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>>> of an
>>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>>> as the
>>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>>> in the
>>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>>> alternative the
>>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key
>>>>>>>>>>> given
>>>>>>>>>>> by an
>>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>>> determine
>>>>>>>>>>> whether the sort key expression is an integer constant, and
>>>>>>>>>>> if so
>>>>>>>>>>> treat
>>>>>>>>>>> it as a column position.
>>>>>>>>>>>
>>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>>> integer
>>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows
>>>>>>>>>>> by the
>>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>>> ASC"
>>>>>>>>>>> and
>>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>>> treated
>>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>>> position
>>>>>>>>>>> then
>>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>>> result
>>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>>
>>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the
>>>>>>>>>>> patch to
>>>>>>>>>>> the
>>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>>
>>>>>>>>>>> The new code is
>>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>>
>>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>>> int i = 0;
>>>>>>>>>>>
>>>>>>>>>>> for(i = 0;
>>>>>>>>>>> i < targetCols.size();
>>>>>>>>>>> i ++){
>>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>>> if(col != null &&
>>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>>> break;
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>>> indexing. The
>>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>>> = 1;
>>>>>>>>>>> i <=
>>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>>
>>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>>> parts of
>>>>>>>>>>> the
>>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>>> resulting
>>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>>
>>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>>> target
>>>>>>>>>>> list,
>>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>>> column in
>>>>>>>>>>> the target list is orderable. This is usually not right.
>>>>>>>>>>> Consider
>>>>>>>>>>> the
>>>>>>>>>>> following SQL:
>>>>>>>>>>>
>>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>>
>>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>>> 'BLOB'
>>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>>> INTERSECT,
>>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>>> that
>>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>>
>>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>>> failing
>>>>>>>>>>> case
>>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to
>>>>>>>>>>> ensure
>>>>>>>>>>> that
>>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>>> separated
>>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>>
>>>>>>>>>>> Jack
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>
>>
>
>
> --------------------------------------------------------------------------------
>
>
>
>> connect 'jdbc:derby:testdb;create=true';
>> create table TENKTUP1 (
>> unique1 int not null,
>> unique2 int not null,
>> two int,
>> four int,
>> ten int,
>> twenty int,
>> onePercent int,
>> tenPercent int,
>> twentyPercent int,
>> fiftyPercent int,
>> unique3 int,
>> evenOnePercent int,
>> oddOnePercent int,
>> stringu1 char(52) not null,
>> stringu2 char(52) not null,
>> string4 char(52)
>> );
>>
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>>
>>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
I have tried your small.sql and result was as next.
--These are evidence for improvement of 134
ij> select * from test_number order by abs(value);
VALUE
-----------
1
2
3
3 rows selected
ij> select * from test_number order by value * -1;
VALUE
-----------
3
2
1
3 rows selected
--This is what was written in small.sql
ij> create table TENKTUP1 (
unique1 int not null,
unique2 int not null,
two int,
four int,
ten int,
twenty int,
onePercent int,
tenPercent int,
twentyPercent int,
fiftyPercent int,
unique3 int,
evenOnePercent int,
oddOnePercent int,
stringu1 char(52) not null,
stringu2 char(52) not null,
string4 char(52)
);
0 rows inserted/updated/deleted
ij> get cursor c as
'select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x';
ij>
Unfortunately, I could not found any ...
And I uploaded derbylang_report.txt to next url.
http://www5.ocn.ne.jp/~tomohito/derbylang_report.txt
Can you find any clue in it ?
Are there any difference between yours ?
If could. I want to yourr derbylang_report...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, March 22, 2005 7:33 AM
Subject: Re: About improvement of DERBY-134
> java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
> writes a test report in suiteName_report.txt. This describes the
> environment, prints a counts of tests that passed and failed, and lists
> all the differences from expected in the failed tests. You can also find
> lists of passed and failed tests in suiteName_pass.txt and
> suiteName_fail.txt. You can also find outputs, diffs, databases, and
> derby.log files for the failed tests, but you have to dig deeper into
> the directories.
>
> When I ran the lang/wisconsin.sql test with your patch it failed. The
> query
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> close c;
> failed to compile, but the test expected it to run. It worked before
> applying the patch, and I believe that it should work.
>
> I boiled the problem down to a small SQL file, which I have attached.
> That file should run without error under ij as long as database "testdb"
> does not exist when you start ij.
>
> I believe that the problem is with the updated bind method in
> OrderByNode. It does not seem to be able to handle correlation names
> from the FROM list. In the example that failed "t" is not the name of an
> actual table, but a correlation name used to name the "(values 1)"
> virtual table.
>
> I tried changing OrderByColumn.bindOrderByColumn to call
> expression.bindExcpression and then eliminating most of the code in
> resolveColumnReference. However this does not work either. Then the
> statement
> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
> (from the lang/orderby.sql test) fails.
>
> I will work on this some more. Perhaps you can continue looking at it
> also.
>
> Jack
>
> TomohitoNakayama wrote:
>
>> I have tried derbylang test suite , but could not found error which
>> was reported .
>>
>> What I found was just difference around "lang/floattypes.sql".
>> I 'm not sure this is error or not yet.
>>
>> Back to reported bug, the next is the test sql in my wisconsin.sql.
>> ====================
>> -- Values clause is a single-row result set, so should not cause
>> optimizer
>> -- to require sort.
>>
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> close c;
>>
>> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>>
>> commit;
>>
>> -- Try with a join on unique column and order on non-unique column
>> ===================
>> I couldn't find difference between what in your mail.
>>
>>
>>
>> Next is svn-status of my wisconsin.sql.
>> ===================
>> $ svn status -v wisconsin.sql
>> 157254 122528 djd wisconsin.sql
>> ===================
>>
>> Is this caused by versioning problem of wisconsin.sql ...?
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, March 19, 2005 3:42 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Thank you for your checking.
>>>
>>> I did'nt know way to test whole sqls.
>>> Sorry for insufficient test.
>>>
>>> Now I will try whole test.
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, March 19, 2005 9:04 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>>> failed. The problem output was:
>>>>
>>>> ij> -- Values clause is a single-row result set, so should not cause
>>>> optimizer
>>>> -- to require sort.
>>>> get cursor c as
>>>> 'select * from TENKTUP1, (values 1) as t(x)
>>>> where TENKTUP1.unique1 = t.x
>>>> order by TENKTUP1.unique1, t.x';
>>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which it
>>>> appears.
>>>>
>>>> This error is incorrect.
>>>>
>>>> There must be a problem in the way that the patch binds the ORDER BY
>>>> expressions. I don't have time to look more deeply into it now.
>>>>
>>>> You should probably run at least the derbylang test suite before
>>>> submitting a patch for ORDER BY.
>>>>
>>>> To do this, change into an empty directory and run
>>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>>> suite takes 5 or 6 hours.
>>>>
>>>> In order to run just the wisconsin.sql test change into an empty
>>>> directory and run
>>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>>> lang/wisconsin.sql
>>>>
>>>> Jack Klebanoff
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> Thank for your checking.
>>>>> I have solved the 2 problems.
>>>>> Attached file is new patch.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> The new patch looks much better. However, I found two problems, one
>>>>>> serious and the other minor.
>>>>>>
>>>>>> The serious problem is that INTERSECT no longer works. The
>>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>>> problem
>>>>>> is in the
>>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>>
>>>>>> method. It attempts to create OrderByColumns by calling
>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>> cm)
>>>>>> This used to work. Now OrderByColumn.init throws a ClassCastException
>>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>>
>>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>>> ValueNode. I think that
>>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>>> cm),
>>>>>> cm)
>>>>>> works.
>>>>>>
>>>>>> The minor problem is that the javadoc for OrderByColumn.init( Object
>>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>>
>>>>>> Jack Klebanoff
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> I have finished coding and testing in orderby.sql.
>>>>>>> I'm not sure test is enough.
>>>>>>>
>>>>>>> Would you please review it ?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>>> <sa...@sourcery.org>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> Hi Tomohito Nakayama,
>>>>>>>>
>>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>>> on an
>>>>>>>> important enhancement that not only yourself but other developpers
>>>>>>>> have
>>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>>> working on
>>>>>>>> this and post any questions or comments you might have. You are
>>>>>>>> pretty
>>>>>>>> close to addressing all issues.
>>>>>>>>
>>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>>> further.
>>>>>>>>
>>>>>>>> Satheesh
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>> Thanks for your reviewing.
>>>>>>>>>
>>>>>>>>> About 1:
>>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>>> A little challenging but worth for it.
>>>>>>>>> I will try.
>>>>>>>>>
>>>>>>>>> About 2:
>>>>>>>>> Uh oh.
>>>>>>>>> Bug about starting value of element indexing in
>>>>>>>>> ResultColumnList ....
>>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>>> orderby.sql
>>>>>>>>> was needed.....
>>>>>>>>>
>>>>>>>>> About 3:
>>>>>>>>> I see.
>>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>>
>>>>>>>>> I will continue this issue.
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>>
>>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Sorry.
>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>
>>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>>
>>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>>
>>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>>> done.
>>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>>> are:
>>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>>>>>> patch
>>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>>> both
>>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>>> rewrite or
>>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>>> select i
>>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>>>>>> You
>>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>>> part of
>>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>>
>>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Woops.
>>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello.
>>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>>
>>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>>> order
>>>>>>>>>>>>> clause.
>>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>>
>>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /*
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>>
>>>>>>>>>>>>> Naka
>>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> */
>>>>>>>>>>>>>
>>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>>> fixed
>>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>>>>>> It is
>>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>>
>>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>>> non-reserved
>>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>>> to add
>>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>>> If we
>>>>>>>>>> need
>>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>>> of them
>>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>>
>>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>>> ORDER BY
>>>>>>>>>> sort
>>>>>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>>>>>> parser
>>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>>> ordering. I
>>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>>> OrderByColumn
>>>>>>>>>> class
>>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>>
>>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>>> of an
>>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>>> as the
>>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>>> in the
>>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>>> alternative the
>>>>>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>>>>>> by an
>>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>>> determine
>>>>>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>>>>>> treat
>>>>>>>>>> it as a column position.
>>>>>>>>>>
>>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>>> integer
>>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>>> ASC"
>>>>>>>>>> and
>>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>>> treated
>>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>>> position
>>>>>>>>>> then
>>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>>> result
>>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>>
>>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>>>>>> the
>>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>>
>>>>>>>>>> The new code is
>>>>>>>>>> }else if(expression != null){
>>>>>>>>>>
>>>>>>>>>> ResultColumn col = null;
>>>>>>>>>> int i = 0;
>>>>>>>>>>
>>>>>>>>>> for(i = 0;
>>>>>>>>>> i < targetCols.size();
>>>>>>>>>> i ++){
>>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>>> if(col != null &&
>>>>>>>>>> col.getExpression() == expression){
>>>>>>>>>> break;
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>>> indexing. The
>>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>>> = 1;
>>>>>>>>>> i <=
>>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>>
>>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>>> parts of
>>>>>>>>>> the
>>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>>> resulting
>>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>>
>>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>>> target
>>>>>>>>>> list,
>>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>>> column in
>>>>>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>>>>>> the
>>>>>>>>>> following SQL:
>>>>>>>>>>
>>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>>
>>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>>> 'BLOB'
>>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>>> INTERSECT,
>>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>>> that
>>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>>
>>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>>> failing
>>>>>>>>>> case
>>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>>>>>> that
>>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>>> separated
>>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>>
>>>>>>>>>> Jack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
>
--------------------------------------------------------------------------------
> connect 'jdbc:derby:testdb;create=true';
> create table TENKTUP1 (
> unique1 int not null,
> unique2 int not null,
> two int,
> four int,
> ten int,
> twenty int,
> onePercent int,
> tenPercent int,
> twentyPercent int,
> fiftyPercent int,
> unique3 int,
> evenOnePercent int,
> oddOnePercent int,
> stringu1 char(52) not null,
> stringu2 char(52) not null,
> string4 char(52)
> );
>
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
>
>
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.8.0 - Release Date: 2005/03/21
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
java org.apache.derbyTesting.functionTests.harness.RunSuite suiteName
writes a test report in suiteName_report.txt. This describes the
environment, prints a counts of tests that passed and failed, and lists
all the differences from expected in the failed tests. You can also find
lists of passed and failed tests in suiteName_pass.txt and
suiteName_fail.txt. You can also find outputs, diffs, databases, and
derby.log files for the failed tests, but you have to dig deeper into
the directories.
When I ran the lang/wisconsin.sql test with your patch it failed. The query
get cursor c as
'select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x';
close c;
failed to compile, but the test expected it to run. It worked before
applying the patch, and I believe that it should work.
I boiled the problem down to a small SQL file, which I have attached.
That file should run without error under ij as long as database "testdb"
does not exist when you start ij.
I believe that the problem is with the updated bind method in
OrderByNode. It does not seem to be able to handle correlation names
from the FROM list. In the example that failed "t" is not the name of an
actual table, but a correlation name used to name the "(values 1)"
virtual table.
I tried changing OrderByColumn.bindOrderByColumn to call
expression.bindExcpression and then eliminating most of the code in
resolveColumnReference. However this does not work either. Then the
statement
values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"
(from the lang/orderby.sql test) fails.
I will work on this some more. Perhaps you can continue looking at it also.
Jack
TomohitoNakayama wrote:
> I have tried derbylang test suite , but could not found error which
> was reported .
>
> What I found was just difference around "lang/floattypes.sql".
> I 'm not sure this is error or not yet.
>
> Back to reported bug, the next is the test sql in my wisconsin.sql.
> ====================
> -- Values clause is a single-row result set, so should not cause
> optimizer
> -- to require sort.
>
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> close c;
>
> values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
>
> commit;
>
> -- Try with a join on unique column and order on non-unique column
> ===================
> I couldn't find difference between what in your mail.
>
>
>
> Next is svn-status of my wisconsin.sql.
> ===================
> $ svn status -v wisconsin.sql
> 157254 122528 djd wisconsin.sql
> ===================
>
> Is this caused by versioning problem of wisconsin.sql ...?
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "TomohitoNakayama"
> <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, March 19, 2005 3:42 PM
> Subject: Re: About improvement of DERBY-134
>
>
>> Thank you for your checking.
>>
>> I did'nt know way to test whole sqls.
>> Sorry for insufficient test.
>>
>> Now I will try whole test.
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, March 19, 2005 9:04 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>>> failed. The problem output was:
>>>
>>> ij> -- Values clause is a single-row result set, so should not cause
>>> optimizer
>>> -- to require sort.
>>> get cursor c as
>>> 'select * from TENKTUP1, (values 1) as t(x)
>>> where TENKTUP1.unique1 = t.x
>>> order by TENKTUP1.unique1, t.x';
>>> ERROR 42X10: 'T' is not an exposed table name in the scope in which it
>>> appears.
>>>
>>> This error is incorrect.
>>>
>>> There must be a problem in the way that the patch binds the ORDER BY
>>> expressions. I don't have time to look more deeply into it now.
>>>
>>> You should probably run at least the derbylang test suite before
>>> submitting a patch for ORDER BY.
>>>
>>> To do this, change into an empty directory and run
>>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>>> suite takes 5 or 6 hours.
>>>
>>> In order to run just the wisconsin.sql test change into an empty
>>> directory and run
>>> java org.apache.derbyTesting.functionTests.harness.RunTest
>>> lang/wisconsin.sql
>>>
>>> Jack Klebanoff
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> Thank for your checking.
>>>> I have solved the 2 problems.
>>>> Attached file is new patch.
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> The new patch looks much better. However, I found two problems, one
>>>>> serious and the other minor.
>>>>>
>>>>> The serious problem is that INTERSECT no longer works. The
>>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>>> problem
>>>>> is in the
>>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>>>
>>>>> method. It attempts to create OrderByColumns by calling
>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>> cm)
>>>>> This used to work. Now OrderByColumn.init throws a ClassCastException
>>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>>
>>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>>> ValueNode. I think that
>>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>>> cm),
>>>>> cm)
>>>>> works.
>>>>>
>>>>> The minor problem is that the javadoc for OrderByColumn.init( Object
>>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>>
>>>>> Jack Klebanoff
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> I have finished coding and testing in orderby.sql.
>>>>>> I'm not sure test is enough.
>>>>>>
>>>>>> Would you please review it ?
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>>> <sa...@sourcery.org>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> Hi Tomohito Nakayama,
>>>>>>>
>>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>>> following comments by myself and Jack. I do think you are working
>>>>>>> on an
>>>>>>> important enhancement that not only yourself but other developpers
>>>>>>> have
>>>>>>> expressed interest in. I strongly encourage you to continue
>>>>>>> working on
>>>>>>> this and post any questions or comments you might have. You are
>>>>>>> pretty
>>>>>>> close to addressing all issues.
>>>>>>>
>>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>>> further.
>>>>>>>
>>>>>>> Satheesh
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>> Thanks for your reviewing.
>>>>>>>>
>>>>>>>> About 1:
>>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>>> A little challenging but worth for it.
>>>>>>>> I will try.
>>>>>>>>
>>>>>>>> About 2:
>>>>>>>> Uh oh.
>>>>>>>> Bug about starting value of element indexing in
>>>>>>>> ResultColumnList ....
>>>>>>>> Test of comma separated lists of ORDER BY expressions in
>>>>>>>> orderby.sql
>>>>>>>> was needed.....
>>>>>>>>
>>>>>>>> About 3:
>>>>>>>> I see.
>>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>>
>>>>>>>> I will continue this issue.
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>>> <kl...@sbcglobal.net>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>>
>>>>>>>>>> Would someone review patch please ?
>>>>>>>>>>
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Sorry.
>>>>>>>>>>> Mistaken.
>>>>>>>>>>>
>>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>>
>>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>>
>>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>>> To: Derby Development
>>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>>> done.
>>>>>>>>>>>> Based on a quick review, some of the items to be completed
>>>>>>>>>>>> are:
>>>>>>>>>>>> (there may be more)
>>>>>>>>>>>>
>>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>>>>> patch
>>>>>>>>>>>> is written. Since orderby expression and orderby column can
>>>>>>>>>>>> both
>>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>>> rewrite or
>>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>>> select i
>>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>>>>> You
>>>>>>>>>>>> could add test cases to orderby.sql test that is already
>>>>>>>>>>>> part of
>>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>>
>>>>>>>>>>>> Satheesh
>>>>>>>>>>>>
>>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Woops.
>>>>>>>>>>>> Mistaken.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hello.
>>>>>>>>>>>> My name is Naka.
>>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>>
>>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>>> sensitive way"
>>>>>>>>>>>>
>>>>>>>>>>>> This issue seems to mean that we can't use complex item in
>>>>>>>>>>>> order
>>>>>>>>>>>> clause.
>>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>>
>>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>>
>>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in
>>>>>>>>>>>> "sqlgrammer.jj". 2)
>>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>
>>>>>>>>>>>> /*
>>>>>>>>>>>>
>>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>>
>>>>>>>>>>>> Naka
>>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>>
>>>>>>>>>>>> */
>>>>>>>>>>>>
>>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>>> fixed
>>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>>>>> It is
>>>>>>>>> close, but I have some problems with it.
>>>>>>>>>
>>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>>> non-reserved
>>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>>> to add
>>>>>>>>> it in two places is difficult enough to discover or remember.
>>>>>>>>> If we
>>>>>>>>> need
>>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one
>>>>>>>>> of them
>>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>>
>>>>>>>>> It is not necessary for the parser to recognize 3 cases of
>>>>>>>>> ORDER BY
>>>>>>>>> sort
>>>>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>>>>> parser
>>>>>>>>> treats it as an expression we should still get the right
>>>>>>>>> ordering. I
>>>>>>>>> think that it would better if the parser did so. The
>>>>>>>>> OrderByColumn
>>>>>>>>> class
>>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>>
>>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>>> of an
>>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>>> as the
>>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>>> in the
>>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>>> alternative the
>>>>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>>>>> by an
>>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can
>>>>>>>>> determine
>>>>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>>>>> treat
>>>>>>>>> it as a column position.
>>>>>>>>>
>>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>>> integer
>>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1
>>>>>>>>> ASC"
>>>>>>>>> and
>>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>>> treated
>>>>>>>>> an integer constant sort key expression as a result column
>>>>>>>>> position
>>>>>>>>> then
>>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>>> result
>>>>>>>>> column, which I think is more usefull.
>>>>>>>>>
>>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>>>>> the
>>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>>
>>>>>>>>> The new code is
>>>>>>>>> }else if(expression != null){
>>>>>>>>>
>>>>>>>>> ResultColumn col = null;
>>>>>>>>> int i = 0;
>>>>>>>>>
>>>>>>>>> for(i = 0;
>>>>>>>>> i < targetCols.size();
>>>>>>>>> i ++){
>>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>>> if(col != null &&
>>>>>>>>> col.getExpression() == expression){
>>>>>>>>> break;
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1
>>>>>>>>> indexing. The
>>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i
>>>>>>>>> = 1;
>>>>>>>>> i <=
>>>>>>>>> targetCols.size(); i++)".
>>>>>>>>>
>>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some
>>>>>>>>> parts of
>>>>>>>>> the
>>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>>> resulting
>>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>>
>>>>>>>>> The result is that when the sort key is an expression
>>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the
>>>>>>>>> target
>>>>>>>>> list,
>>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>>> column in
>>>>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>>>>> the
>>>>>>>>> following SQL:
>>>>>>>>>
>>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>>
>>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>>> 'BLOB'
>>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>>> INTERSECT,
>>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for
>>>>>>>>> that
>>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>>
>>>>>>>>> 3. Testing. I would like to see some additional tests: the
>>>>>>>>> failing
>>>>>>>>> case
>>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>>>>> that
>>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>>> separated
>>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>>
>>>>>>>>> Jack
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
I have tried derbylang test suite , but could not found error which was
reported .
What I found was just difference around "lang/floattypes.sql".
I 'm not sure this is error or not yet.
Back to reported bug, the next is the test sql in my wisconsin.sql.
====================
-- Values clause is a single-row result set, so should not cause optimizer
-- to require sort.
get cursor c as
'select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x';
close c;
values SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
commit;
-- Try with a join on unique column and order on non-unique column
===================
I couldn't find difference between what in your mail.
Next is svn-status of my wisconsin.sql.
===================
$ svn status -v wisconsin.sql
157254 122528 djd wisconsin.sql
===================
Is this caused by versioning problem of wisconsin.sql ...?
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, March 19, 2005 3:42 PM
Subject: Re: About improvement of DERBY-134
> Thank you for your checking.
>
> I did'nt know way to test whole sqls.
> Sorry for insufficient test.
>
> Now I will try whole test.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "Jack Klebanoff" <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, March 19, 2005 9:04 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> The derbyall test suite found a problem. The lang/wisconsin.sql test
>> failed. The problem output was:
>>
>> ij> -- Values clause is a single-row result set, so should not cause
>> optimizer
>> -- to require sort.
>> get cursor c as
>> 'select * from TENKTUP1, (values 1) as t(x)
>> where TENKTUP1.unique1 = t.x
>> order by TENKTUP1.unique1, t.x';
>> ERROR 42X10: 'T' is not an exposed table name in the scope in which it
>> appears.
>>
>> This error is incorrect.
>>
>> There must be a problem in the way that the patch binds the ORDER BY
>> expressions. I don't have time to look more deeply into it now.
>>
>> You should probably run at least the derbylang test suite before
>> submitting a patch for ORDER BY.
>>
>> To do this, change into an empty directory and run
>> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
>> The derbylang suite takes about 90 minutes on my laptop. The derbyall
>> suite takes 5 or 6 hours.
>>
>> In order to run just the wisconsin.sql test change into an empty
>> directory and run
>> java org.apache.derbyTesting.functionTests.harness.RunTest
>> lang/wisconsin.sql
>>
>> Jack Klebanoff
>>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> Thank for your checking.
>>> I have solved the 2 problems.
>>> Attached file is new patch.
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Tuesday, March 15, 2005 10:51 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> The new patch looks much better. However, I found two problems, one
>>>> serious and the other minor.
>>>>
>>>> The serious problem is that INTERSECT no longer works. The
>>>> lang/intersect.sql test (part of the derbylang suite) fails. The
>>>> problem
>>>> is in the
>>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>>> method. It attempts to create OrderByColumns by calling
>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>> cm)
>>>> This used to work. Now OrderByColumn.init throws a ClassCastException
>>>> because it expects to be passed a ValueNode, not an Integer.
>>>>
>>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>>> ValueNode. I think that
>>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>>> cm),
>>>> cm)
>>>> works.
>>>>
>>>> The minor problem is that the javadoc for OrderByColumn.init( Object
>>>> expression) documents a "dummy" parameter that no longer exists.
>>>>
>>>> Jack Klebanoff
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I have finished coding and testing in orderby.sql.
>>>>> I'm not sure test is enough.
>>>>>
>>>>> Would you please review it ?
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>>> <sa...@sourcery.org>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Hi Tomohito Nakayama,
>>>>>>
>>>>>> Just wanted to check how you are progressing on the patch update,
>>>>>> following comments by myself and Jack. I do think you are working
>>>>>> on an
>>>>>> important enhancement that not only yourself but other developpers
>>>>>> have
>>>>>> expressed interest in. I strongly encourage you to continue working
>>>>>> on
>>>>>> this and post any questions or comments you might have. You are
>>>>>> pretty
>>>>>> close to addressing all issues.
>>>>>>
>>>>>> I am willing to help, if you need any, to continue taking this
>>>>>> further.
>>>>>>
>>>>>> Satheesh
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>> Thanks for your reviewing.
>>>>>>>
>>>>>>> About 1:
>>>>>>> Handling any sortKey as expression is better structure.
>>>>>>> A little challenging but worth for it.
>>>>>>> I will try.
>>>>>>>
>>>>>>> About 2:
>>>>>>> Uh oh.
>>>>>>> Bug about starting value of element indexing in ResultColumnList
>>>>>>> ....
>>>>>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>>>>>> was needed.....
>>>>>>>
>>>>>>> About 3:
>>>>>>> I see.
>>>>>>> It seems that it is certainly needed to add test case .
>>>>>>>
>>>>>>> I will continue this issue.
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>>> <kl...@sbcglobal.net>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>>
>>>>>>>>> Would someone review patch please ?
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Sorry.
>>>>>>>>>> Mistaken.
>>>>>>>>>>
>>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>>
>>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>>
>>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>>
>>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>>> To: Derby Development
>>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>>> done.
>>>>>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>>>>>> (there may be more)
>>>>>>>>>>>
>>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>>>> patch
>>>>>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>>> rewrite or
>>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>>> select i
>>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>>>> You
>>>>>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>>
>>>>>>>>>>> Satheesh
>>>>>>>>>>>
>>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>>
>>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Woops.
>>>>>>>>>>> Mistaken.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>> sensitive way"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>>> sensitive way"
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello.
>>>>>>>>>>> My name is Naka.
>>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>>
>>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>>
>>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>>> sensitive way"
>>>>>>>>>>>
>>>>>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>>>>>> clause.
>>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>>
>>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>>
>>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>>
>>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj".
>>>>>>>>>>> 2)
>>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>>
>>>>>>>>>>> Best regards.
>>>>>>>>>>>
>>>>>>>>>>> /*
>>>>>>>>>>>
>>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>>
>>>>>>>>>>> Naka
>>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>>
>>>>>>>>>>> */
>>>>>>>>>>>
>>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>>> fixed
>>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>>>> It is
>>>>>>>> close, but I have some problems with it.
>>>>>>>>
>>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>>> non-reserved
>>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>>> to add
>>>>>>>> it in two places is difficult enough to discover or remember. If we
>>>>>>>> need
>>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one of
>>>>>>>> them
>>>>>>>> keeps the list of non-reserved key words.
>>>>>>>>
>>>>>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>>>>>> sort
>>>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>>>> parser
>>>>>>>> treats it as an expression we should still get the right ordering.
>>>>>>>> I
>>>>>>>> think that it would better if the parser did so. The OrderByColumn
>>>>>>>> class
>>>>>>>> can special case a simple column reference expression, as an
>>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>>
>>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>>> of an
>>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>>> as the
>>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>>> in the
>>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>>> alternative the
>>>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>>>> by an
>>>>>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>>>> treat
>>>>>>>> it as a column position.
>>>>>>>>
>>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>>> integer
>>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>>>>>> and
>>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>>> treated
>>>>>>>> an integer constant sort key expression as a result column position
>>>>>>>> then
>>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>>> result
>>>>>>>> column, which I think is more usefull.
>>>>>>>>
>>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>>>> the
>>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>>
>>>>>>>> The new code is
>>>>>>>> }else if(expression != null){
>>>>>>>>
>>>>>>>> ResultColumn col = null;
>>>>>>>> int i = 0;
>>>>>>>>
>>>>>>>> for(i = 0;
>>>>>>>> i < targetCols.size();
>>>>>>>> i ++){
>>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>>> if(col != null &&
>>>>>>>> col.getExpression() == expression){
>>>>>>>> break;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>>>>>> i <=
>>>>>>>> targetCols.size(); i++)".
>>>>>>>>
>>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>>>>>> the
>>>>>>>> Derby code use 0 indexing while others use 1 indexing. The
>>>>>>>> resulting
>>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>>
>>>>>>>> The result is that when the sort key is an expression
>>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>>>>>> list,
>>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>>> column in
>>>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>>>> the
>>>>>>>> following SQL:
>>>>>>>>
>>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>>> select id,b from tblob order by abs(id);
>>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>>
>>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>>> 'BLOB'
>>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>>> INTERSECT,
>>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>>>>>> type". The second SELECT executes properly.
>>>>>>>>
>>>>>>>> 3. Testing. I would like to see some additional tests: the failing
>>>>>>>> case
>>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>>>> that
>>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>>> separated
>>>>>>>> lists of ORDER BY expressions.
>>>>>>>>
>>>>>>>> Jack
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Thank you for your checking.
I did'nt know way to test whole sqls.
Sorry for insufficient test.
Now I will try whole test.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, March 19, 2005 9:04 AM
Subject: Re: About improvement of DERBY-134
> The derbyall test suite found a problem. The lang/wisconsin.sql test
> failed. The problem output was:
>
> ij> -- Values clause is a single-row result set, so should not cause
> optimizer
> -- to require sort.
> get cursor c as
> 'select * from TENKTUP1, (values 1) as t(x)
> where TENKTUP1.unique1 = t.x
> order by TENKTUP1.unique1, t.x';
> ERROR 42X10: 'T' is not an exposed table name in the scope in which it
> appears.
>
> This error is incorrect.
>
> There must be a problem in the way that the patch binds the ORDER BY
> expressions. I don't have time to look more deeply into it now.
>
> You should probably run at least the derbylang test suite before
> submitting a patch for ORDER BY.
>
> To do this, change into an empty directory and run
> java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
> The derbylang suite takes about 90 minutes on my laptop. The derbyall
> suite takes 5 or 6 hours.
>
> In order to run just the wisconsin.sql test change into an empty
> directory and run
> java org.apache.derbyTesting.functionTests.harness.RunTest
> lang/wisconsin.sql
>
> Jack Klebanoff
>
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> Thank for your checking.
>> I have solved the 2 problems.
>> Attached file is new patch.
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Tuesday, March 15, 2005 10:51 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> The new patch looks much better. However, I found two problems, one
>>> serious and the other minor.
>>>
>>> The serious problem is that INTERSECT no longer works. The
>>> lang/intersect.sql test (part of the derbylang suite) fails. The problem
>>> is in the
>>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>>> method. It attempts to create OrderByColumns by calling
>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>> cm)
>>> This used to work. Now OrderByColumn.init throws a ClassCastException
>>> because it expects to be passed a ValueNode, not an Integer.
>>>
>>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>>> ValueNode. I think that
>>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>>> cm),
>>> cm)
>>> works.
>>>
>>> The minor problem is that the javadoc for OrderByColumn.init( Object
>>> expression) documents a "dummy" parameter that no longer exists.
>>>
>>> Jack Klebanoff
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> I have finished coding and testing in orderby.sql.
>>>> I'm not sure test is enough.
>>>>
>>>> Would you please review it ?
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>>> <sa...@sourcery.org>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Saturday, March 12, 2005 6:59 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Hi Tomohito Nakayama,
>>>>>
>>>>> Just wanted to check how you are progressing on the patch update,
>>>>> following comments by myself and Jack. I do think you are working
>>>>> on an
>>>>> important enhancement that not only yourself but other developpers
>>>>> have
>>>>> expressed interest in. I strongly encourage you to continue working on
>>>>> this and post any questions or comments you might have. You are pretty
>>>>> close to addressing all issues.
>>>>>
>>>>> I am willing to help, if you need any, to continue taking this
>>>>> further.
>>>>>
>>>>> Satheesh
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>> Thanks for your reviewing.
>>>>>>
>>>>>> About 1:
>>>>>> Handling any sortKey as expression is better structure.
>>>>>> A little challenging but worth for it.
>>>>>> I will try.
>>>>>>
>>>>>> About 2:
>>>>>> Uh oh.
>>>>>> Bug about starting value of element indexing in ResultColumnList ....
>>>>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>>>>> was needed.....
>>>>>>
>>>>>> About 3:
>>>>>> I see.
>>>>>> It seems that it is certainly needed to add test case .
>>>>>>
>>>>>> I will continue this issue.
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>>> <kl...@sbcglobal.net>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>>> add some test pattern to orderby.sql.
>>>>>>>>
>>>>>>>> Would someone review patch please ?
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sorry.
>>>>>>>>> Mistaken.
>>>>>>>>>
>>>>>>>>> LOOKAHEAD()....
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>>
>>>>>>>>>> Thank's for your reviewing.
>>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>>
>>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>>
>>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>>
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>>> To: Derby Development
>>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>>> done.
>>>>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>>>>> (there may be more)
>>>>>>>>>>
>>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>>> patch
>>>>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>>> rewrite or
>>>>>>>>>> add lookup to avoid this.
>>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>>> select i
>>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>>> You
>>>>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>>>>> functionTests/tests/lang.
>>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>>
>>>>>>>>>> Satheesh
>>>>>>>>>>
>>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>>
>>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Woops.
>>>>>>>>>> Mistaken.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>> sensitive way"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>>> sensitive way"
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello.
>>>>>>>>>> My name is Naka.
>>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>>
>>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>>> And found a interesting issue.
>>>>>>>>>>
>>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>>> sensitive way"
>>>>>>>>>>
>>>>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>>>>> clause.
>>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>>
>>>>>>>>>> Solving this isn't useful?
>>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>>
>>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>>
>>>>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>>
>>>>>>>>>> Best regards.
>>>>>>>>>>
>>>>>>>>>> /*
>>>>>>>>>>
>>>>>>>>>> Tomohito Nakayama
>>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>>
>>>>>>>>>> Naka
>>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>>
>>>>>>>>>> */
>>>>>>>>>>
>>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>>> fixed
>>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>>> It is
>>>>>>> close, but I have some problems with it.
>>>>>>>
>>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>>> non-reserved
>>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>>> to add
>>>>>>> it in two places is difficult enough to discover or remember. If we
>>>>>>> need
>>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>>>>>> keeps the list of non-reserved key words.
>>>>>>>
>>>>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>>>>> sort
>>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>>> parser
>>>>>>> treats it as an expression we should still get the right ordering. I
>>>>>>> think that it would better if the parser did so. The OrderByColumn
>>>>>>> class
>>>>>>> can special case a simple column reference expression, as an
>>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>>
>>>>>>> The only sort key type that has to be handled specially is that
>>>>>>> of an
>>>>>>> integer constant. That specifies one of the select list columns
>>>>>>> as the
>>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>>> in the
>>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>>> alternative the
>>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>>> by an
>>>>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>>> treat
>>>>>>> it as a column position.
>>>>>>>
>>>>>>> The two alternatives differ in the way that they treat constant
>>>>>>> integer
>>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>>>>> and
>>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>>> treated
>>>>>>> an integer constant sort key expression as a result column position
>>>>>>> then
>>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>>> result
>>>>>>> column, which I think is more usefull.
>>>>>>>
>>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>>> the
>>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>>
>>>>>>> The new code is
>>>>>>> }else if(expression != null){
>>>>>>>
>>>>>>> ResultColumn col = null;
>>>>>>> int i = 0;
>>>>>>>
>>>>>>> for(i = 0;
>>>>>>> i < targetCols.size();
>>>>>>> i ++){
>>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>>> if(col != null &&
>>>>>>> col.getExpression() == expression){
>>>>>>> break;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>>>>> i <=
>>>>>>> targetCols.size(); i++)".
>>>>>>>
>>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>>>>> the
>>>>>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>>>>>> confusion has caught most of us at one time or another).
>>>>>>>
>>>>>>> The result is that when the sort key is an expression
>>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>>>>> list,
>>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>>> column in
>>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>>> the
>>>>>>> following SQL:
>>>>>>>
>>>>>>> create table tblob( id int, b blob(1000));
>>>>>>> select id,b from tblob order by abs(id);
>>>>>>> select b,id from tblob order by abs(id);
>>>>>>>
>>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>>> 'BLOB'
>>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>>> INTERSECT,
>>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>>>>> type". The second SELECT executes properly.
>>>>>>>
>>>>>>> 3. Testing. I would like to see some additional tests: the failing
>>>>>>> case
>>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>>> that
>>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>>> separated
>>>>>>> lists of ORDER BY expressions.
>>>>>>>
>>>>>>> Jack
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 2005/03/18
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
The derbyall test suite found a problem. The lang/wisconsin.sql test
failed. The problem output was:
ij> -- Values clause is a single-row result set, so should not cause
optimizer
-- to require sort.
get cursor c as
'select * from TENKTUP1, (values 1) as t(x)
where TENKTUP1.unique1 = t.x
order by TENKTUP1.unique1, t.x';
ERROR 42X10: 'T' is not an exposed table name in the scope in which it
appears.
This error is incorrect.
There must be a problem in the way that the patch binds the ORDER BY
expressions. I don't have time to look more deeply into it now.
You should probably run at least the derbylang test suite before
submitting a patch for ORDER BY.
To do this, change into an empty directory and run
java org.apache.derbyTesting.functionTests.harness.RunSuite derbylang
The derbylang suite takes about 90 minutes on my laptop. The derbyall
suite takes 5 or 6 hours.
In order to run just the wisconsin.sql test change into an empty
directory and run
java org.apache.derbyTesting.functionTests.harness.RunTest
lang/wisconsin.sql
Jack Klebanoff
TomohitoNakayama wrote:
> Hello.
>
> Thank for your checking.
> I have solved the 2 problems.
> Attached file is new patch.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Jack Klebanoff"
> <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Tuesday, March 15, 2005 10:51 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> The new patch looks much better. However, I found two problems, one
>> serious and the other minor.
>>
>> The serious problem is that INTERSECT no longer works. The
>> lang/intersect.sql test (part of the derbylang suite) fails. The problem
>> is in the
>> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
>> method. It attempts to create OrderByColumns by calling
>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>> cm)
>> This used to work. Now OrderByColumn.init throws a ClassCastException
>> because it expects to be passed a ValueNode, not an Integer.
>>
>> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
>> ValueNode. I think that
>> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
>> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
>> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
>> cm),
>> cm)
>> works.
>>
>> The minor problem is that the javadoc for OrderByColumn.init( Object
>> expression) documents a "dummy" parameter that no longer exists.
>>
>> Jack Klebanoff
>>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I have finished coding and testing in orderby.sql.
>>> I'm not sure test is enough.
>>>
>>> Would you please review it ?
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Satheesh Bandaram"
>>> <sa...@sourcery.org>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Saturday, March 12, 2005 6:59 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Hi Tomohito Nakayama,
>>>>
>>>> Just wanted to check how you are progressing on the patch update,
>>>> following comments by myself and Jack. I do think you are working
>>>> on an
>>>> important enhancement that not only yourself but other developpers
>>>> have
>>>> expressed interest in. I strongly encourage you to continue working on
>>>> this and post any questions or comments you might have. You are pretty
>>>> close to addressing all issues.
>>>>
>>>> I am willing to help, if you need any, to continue taking this
>>>> further.
>>>>
>>>> Satheesh
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>> Thanks for your reviewing.
>>>>>
>>>>> About 1:
>>>>> Handling any sortKey as expression is better structure.
>>>>> A little challenging but worth for it.
>>>>> I will try.
>>>>>
>>>>> About 2:
>>>>> Uh oh.
>>>>> Bug about starting value of element indexing in ResultColumnList ....
>>>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>>>> was needed.....
>>>>>
>>>>> About 3:
>>>>> I see.
>>>>> It seems that it is certainly needed to add test case .
>>>>>
>>>>> I will continue this issue.
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>>> <kl...@sbcglobal.net>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>>> add some test pattern to orderby.sql.
>>>>>>>
>>>>>>> Would someone review patch please ?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> Sorry.
>>>>>>>> Mistaken.
>>>>>>>>
>>>>>>>> LOOKAHEAD()....
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>>
>>>>>>>>> Thank's for your reviewing.
>>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>>
>>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>>
>>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>>> To: Derby Development
>>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think the patch is a good start. But more work needs to be
>>>>>>>>> done.
>>>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>>>> (there may be more)
>>>>>>>>>
>>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>>> patch
>>>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>>>> start with an identifier, this causes ambiguity. Need to
>>>>>>>>> rewrite or
>>>>>>>>> add lookup to avoid this.
>>>>>>>>> Current patch doesn't seem to support all expressions, Ex:
>>>>>>>>> select i
>>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>>> Add more test cases and test outputs to show changed behavior.
>>>>>>>>> You
>>>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>>>> functionTests/tests/lang.
>>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>>
>>>>>>>>> Satheesh
>>>>>>>>>
>>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>>
>>>>>>>>> I tried to solve DERBY-134.
>>>>>>>>> Patch is attached to this mail.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Woops.
>>>>>>>>> Mistaken.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>> sensitive way"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>>> sensitive way"
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>>> To: <de...@db.apache.org>
>>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello.
>>>>>>>>> My name is Naka.
>>>>>>>>> I'm very newbie in derby community.
>>>>>>>>>
>>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>>> And found a interesting issue.
>>>>>>>>>
>>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>>> sensitive way"
>>>>>>>>>
>>>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>>>> clause.
>>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>>
>>>>>>>>> Solving this isn't useful?
>>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>>
>>>>>>>>> What I think we need to do is as next:
>>>>>>>>>
>>>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>>
>>>>>>>>> Tomohito Nakayama
>>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>>
>>>>>>>>> Naka
>>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>>
>>>>>>>>> */
>>>>>>>>>
>>>>>> I have worked on Derby/Cloudscape for a few years and have even
>>>>>> fixed
>>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>>> It is
>>>>>> close, but I have some problems with it.
>>>>>>
>>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>>> isNonReservedKeyword() to determine whether a token is a
>>>>>> non-reserved
>>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having
>>>>>> to add
>>>>>> it in two places is difficult enough to discover or remember. If we
>>>>>> need
>>>>>> isNonReservedKeyword then we should find a way of combining
>>>>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>>>>> keeps the list of non-reserved key words.
>>>>>>
>>>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>>>> sort
>>>>>> key type. A column name is just one kind of <expression>. If the
>>>>>> parser
>>>>>> treats it as an expression we should still get the right ordering. I
>>>>>> think that it would better if the parser did so. The OrderByColumn
>>>>>> class
>>>>>> can special case a simple column reference expression, as an
>>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>>
>>>>>> The only sort key type that has to be handled specially is that
>>>>>> of an
>>>>>> integer constant. That specifies one of the select list columns
>>>>>> as the
>>>>>> sort key. This case can be recognized in the parser, as is done
>>>>>> in the
>>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>>> alternative the
>>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>>> by an
>>>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>>>> whether the sort key expression is an integer constant, and if so
>>>>>> treat
>>>>>> it as a column position.
>>>>>>
>>>>>> The two alternatives differ in the way that they treat constant
>>>>>> integer
>>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>>>> and
>>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>>> treated
>>>>>> an integer constant sort key expression as a result column position
>>>>>> then
>>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first
>>>>>> result
>>>>>> column, which I think is more usefull.
>>>>>>
>>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to
>>>>>> the
>>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>>
>>>>>> The new code is
>>>>>> }else if(expression != null){
>>>>>>
>>>>>> ResultColumn col = null;
>>>>>> int i = 0;
>>>>>>
>>>>>> for(i = 0;
>>>>>> i < targetCols.size();
>>>>>> i ++){
>>>>>> col = targetCols.getOrderByColumn(i);
>>>>>> if(col != null &&
>>>>>> col.getExpression() == expression){
>>>>>> break;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>>>> i <=
>>>>>> targetCols.size(); i++)".
>>>>>>
>>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>>>> the
>>>>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>>>>> confusion has caught most of us at one time or another).
>>>>>>
>>>>>> The result is that when the sort key is an expression
>>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>>>> list,
>>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>>> column in
>>>>>> the target list is orderable. This is usually not right. Consider
>>>>>> the
>>>>>> following SQL:
>>>>>>
>>>>>> create table tblob( id int, b blob(1000));
>>>>>> select id,b from tblob order by abs(id);
>>>>>> select b,id from tblob order by abs(id);
>>>>>>
>>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type
>>>>>> 'BLOB'
>>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION,
>>>>>> INTERSECT,
>>>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>>>> type". The second SELECT executes properly.
>>>>>>
>>>>>> 3. Testing. I would like to see some additional tests: the failing
>>>>>> case
>>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure
>>>>>> that
>>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>>> separated
>>>>>> lists of ORDER BY expressions.
>>>>>>
>>>>>> Jack
>>>>>>
>>>>>>
>>>>>>
>>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thank for your checking.
I have solved the 2 problems.
Attached file is new patch.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Tuesday, March 15, 2005 10:51 AM
Subject: Re: About improvement of DERBY-134
> The new patch looks much better. However, I found two problems, one
> serious and the other minor.
>
> The serious problem is that INTERSECT no longer works. The
> lang/intersect.sql test (part of the derbylang suite) fails. The problem
> is in the
> org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
> method. It attempts to create OrderByColumns by calling
> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
> cm)
> This used to work. Now OrderByColumn.init throws a ClassCastException
> because it expects to be passed a ValueNode, not an Integer.
>
> IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
> ValueNode. I think that
> nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
> nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
> ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
> cm),
> cm)
> works.
>
> The minor problem is that the javadoc for OrderByColumn.init( Object
> expression) documents a "dummy" parameter that no longer exists.
>
> Jack Klebanoff
>
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I have finished coding and testing in orderby.sql.
>> I'm not sure test is enough.
>>
>> Would you please review it ?
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Satheesh Bandaram"
>> <sa...@sourcery.org>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Saturday, March 12, 2005 6:59 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Hi Tomohito Nakayama,
>>>
>>> Just wanted to check how you are progressing on the patch update,
>>> following comments by myself and Jack. I do think you are working on an
>>> important enhancement that not only yourself but other developpers have
>>> expressed interest in. I strongly encourage you to continue working on
>>> this and post any questions or comments you might have. You are pretty
>>> close to addressing all issues.
>>>
>>> I am willing to help, if you need any, to continue taking this further.
>>>
>>> Satheesh
>>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>> Thanks for your reviewing.
>>>>
>>>> About 1:
>>>> Handling any sortKey as expression is better structure.
>>>> A little challenging but worth for it.
>>>> I will try.
>>>>
>>>> About 2:
>>>> Uh oh.
>>>> Bug about starting value of element indexing in ResultColumnList ....
>>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>>> was needed.....
>>>>
>>>> About 3:
>>>> I see.
>>>> It seems that it is certainly needed to add test case .
>>>>
>>>> I will continue this issue.
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "Jack Klebanoff"
>>>> <kl...@sbcglobal.net>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Sunday, February 20, 2005 8:37 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>>> add some test pattern to orderby.sql.
>>>>>>
>>>>>> Would someone review patch please ?
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> Sorry.
>>>>>>> Mistaken.
>>>>>>>
>>>>>>> LOOKAHEAD()....
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>> Hello.
>>>>>>>>
>>>>>>>> Thank's for your reviewing.
>>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>>
>>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>>
>>>>>>>> #World is not simple as I wish to be.....
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>>> To: Derby Development
>>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>> I think the patch is a good start. But more work needs to be done.
>>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>>> (there may be more)
>>>>>>>>
>>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>>> patch
>>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>>>>> add lookup to avoid this.
>>>>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>>> functionTests/tests/lang.
>>>>>>>> I do encourage you to continue work on this ...
>>>>>>>>
>>>>>>>> Satheesh
>>>>>>>>
>>>>>>>> TomohitoNakayama wrote:
>>>>>>>>
>>>>>>>> I tried to solve DERBY-134.
>>>>>>>> Patch is attached to this mail.
>>>>>>>>
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Woops.
>>>>>>>> Mistaken.
>>>>>>>>
>>>>>>>>
>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>> sensitive way"
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>>> sensitive way"
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>>> To: <de...@db.apache.org>
>>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello.
>>>>>>>> My name is Naka.
>>>>>>>> I'm very newbie in derby community.
>>>>>>>>
>>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>>> And found a interesting issue.
>>>>>>>>
>>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>>> sensitive way"
>>>>>>>>
>>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>>> clause.
>>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>>
>>>>>>>> Solving this isn't useful?
>>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>>
>>>>>>>> What I think we need to do is as next:
>>>>>>>>
>>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> /*
>>>>>>>>
>>>>>>>> Tomohito Nakayama
>>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>>
>>>>>>>> Naka
>>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>>
>>>>>>>> */
>>>>>>>>
>>>>> I have worked on Derby/Cloudscape for a few years and have even fixed
>>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>>> It is
>>>>> close, but I have some problems with it.
>>>>>
>>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>>> isNonReservedKeyword() to determine whether a token is a non-reserved
>>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>>> non-reserved keyword we must add it to the list of tokens, to
>>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>>>>> it in two places is difficult enough to discover or remember. If we
>>>>> need
>>>>> isNonReservedKeyword then we should find a way of combining
>>>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>>>> keeps the list of non-reserved key words.
>>>>>
>>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>>> sort
>>>>> key type. A column name is just one kind of <expression>. If the
>>>>> parser
>>>>> treats it as an expression we should still get the right ordering. I
>>>>> think that it would better if the parser did so. The OrderByColumn
>>>>> class
>>>>> can special case a simple column reference expression, as an
>>>>> optimization. This considerably simplifies parsing sort keys.
>>>>>
>>>>> The only sort key type that has to be handled specially is that of an
>>>>> integer constant. That specifies one of the select list columns as the
>>>>> sort key. This case can be recognized in the parser, as is done in the
>>>>> patch, or it can be recognized in OrderByColumn. In this
>>>>> alternative the
>>>>> parser always creates OrderByColumn nodes with the sort key given
>>>>> by an
>>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>>> whether the sort key expression is an integer constant, and if so
>>>>> treat
>>>>> it as a column position.
>>>>>
>>>>> The two alternatives differ in the way that they treat constant
>>>>> integer
>>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>>> and
>>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>>> treated
>>>>> an integer constant sort key expression as a result column position
>>>>> then
>>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>>>>> column, which I think is more usefull.
>>>>>
>>>>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>>>>> bindOrderByColumn method of class OrderByColumn.
>>>>>
>>>>> The new code is
>>>>> }else if(expression != null){
>>>>>
>>>>> ResultColumn col = null;
>>>>> int i = 0;
>>>>>
>>>>> for(i = 0;
>>>>> i < targetCols.size();
>>>>> i ++){
>>>>> col = targetCols.getOrderByColumn(i);
>>>>> if(col != null &&
>>>>> col.getExpression() == expression){
>>>>> break;
>>>>> }
>>>>> }
>>>>>
>>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>>> i <=
>>>>> targetCols.size(); i++)".
>>>>>
>>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>>> the
>>>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>>>> confusion has caught most of us at one time or another).
>>>>>
>>>>> The result is that when the sort key is an expression
>>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>>> list,
>>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>>> column in
>>>>> the target list is orderable. This is usually not right. Consider the
>>>>> following SQL:
>>>>>
>>>>> create table tblob( id int, b blob(1000));
>>>>> select id,b from tblob order by abs(id);
>>>>> select b,id from tblob order by abs(id);
>>>>>
>>>>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>>> type". The second SELECT executes properly.
>>>>>
>>>>> 3. Testing. I would like to see some additional tests: the failing
>>>>> case
>>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>>> separated
>>>>> lists of ORDER BY expressions.
>>>>>
>>>>> Jack
>>>>>
>>>>>
>>>>>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
The new patch looks much better. However, I found two problems, one
serious and the other minor.
The serious problem is that INTERSECT no longer works. The
lang/intersect.sql test (part of the derbylang suite) fails. The problem
is in the
org.apache.derby.impl.sql.compile.IntersectOrExceptNode.pushOrderingDown
method. It attempts to create OrderByColumns by calling
nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
cm)
This used to work. Now OrderByColumn.init throws a ClassCastException
because it expects to be passed a ValueNode, not an Integer.
IntersectOrExceptNode.pushOrderingDown has to be changed to pass a
ValueNode. I think that
nf.getNode( C_NodeTypes.ORDER_BY_COLUMN,
nf.getNode( C_NodeTypes.INT_CONSTANT_NODE,
ReuseFactory.getInteger( intermediateOrderByColumns[i] + 1),
cm),
cm)
works.
The minor problem is that the javadoc for OrderByColumn.init( Object
expression) documents a "dummy" parameter that no longer exists.
Jack Klebanoff
TomohitoNakayama wrote:
> Hello.
>
> I have finished coding and testing in orderby.sql.
> I'm not sure test is enough.
>
> Would you please review it ?
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Satheesh Bandaram"
> <sa...@sourcery.org>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, March 12, 2005 6:59 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> Hi Tomohito Nakayama,
>>
>> Just wanted to check how you are progressing on the patch update,
>> following comments by myself and Jack. I do think you are working on an
>> important enhancement that not only yourself but other developpers have
>> expressed interest in. I strongly encourage you to continue working on
>> this and post any questions or comments you might have. You are pretty
>> close to addressing all issues.
>>
>> I am willing to help, if you need any, to continue taking this further.
>>
>> Satheesh
>>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>> Thanks for your reviewing.
>>>
>>> About 1:
>>> Handling any sortKey as expression is better structure.
>>> A little challenging but worth for it.
>>> I will try.
>>>
>>> About 2:
>>> Uh oh.
>>> Bug about starting value of element indexing in ResultColumnList ....
>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>> was needed.....
>>>
>>> About 3:
>>> I see.
>>> It seems that it is certainly needed to add test case .
>>>
>>> I will continue this issue.
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Sunday, February 20, 2005 8:37 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>> add some test pattern to orderby.sql.
>>>>>
>>>>> Would someone review patch please ?
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Sorry.
>>>>>> Mistaken.
>>>>>>
>>>>>> LOOKAHEAD()....
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> Thank's for your reviewing.
>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>
>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>
>>>>>>> #World is not simple as I wish to be.....
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>> To: Derby Development
>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>> I think the patch is a good start. But more work needs to be done.
>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>> (there may be more)
>>>>>>>
>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>> patch
>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>>>> add lookup to avoid this.
>>>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>> functionTests/tests/lang.
>>>>>>> I do encourage you to continue work on this ...
>>>>>>>
>>>>>>> Satheesh
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>> I tried to solve DERBY-134.
>>>>>>> Patch is attached to this mail.
>>>>>>>
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Woops.
>>>>>>> Mistaken.
>>>>>>>
>>>>>>>
>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: <de...@db.apache.org>
>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello.
>>>>>>> My name is Naka.
>>>>>>> I'm very newbie in derby community.
>>>>>>>
>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>> And found a interesting issue.
>>>>>>>
>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>> clause.
>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>
>>>>>>> Solving this isn't useful?
>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>
>>>>>>> What I think we need to do is as next:
>>>>>>>
>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>>
>>>> I have worked on Derby/Cloudscape for a few years and have even fixed
>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>> It is
>>>> close, but I have some problems with it.
>>>>
>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>> isNonReservedKeyword() to determine whether a token is a non-reserved
>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>> non-reserved keyword we must add it to the list of tokens, to
>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>>>> it in two places is difficult enough to discover or remember. If we
>>>> need
>>>> isNonReservedKeyword then we should find a way of combining
>>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>>> keeps the list of non-reserved key words.
>>>>
>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>> sort
>>>> key type. A column name is just one kind of <expression>. If the
>>>> parser
>>>> treats it as an expression we should still get the right ordering. I
>>>> think that it would better if the parser did so. The OrderByColumn
>>>> class
>>>> can special case a simple column reference expression, as an
>>>> optimization. This considerably simplifies parsing sort keys.
>>>>
>>>> The only sort key type that has to be handled specially is that of an
>>>> integer constant. That specifies one of the select list columns as the
>>>> sort key. This case can be recognized in the parser, as is done in the
>>>> patch, or it can be recognized in OrderByColumn. In this
>>>> alternative the
>>>> parser always creates OrderByColumn nodes with the sort key given
>>>> by an
>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>> whether the sort key expression is an integer constant, and if so
>>>> treat
>>>> it as a column position.
>>>>
>>>> The two alternatives differ in the way that they treat constant
>>>> integer
>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>> and
>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>> treated
>>>> an integer constant sort key expression as a result column position
>>>> then
>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>>>> column, which I think is more usefull.
>>>>
>>>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>>>> bindOrderByColumn method of class OrderByColumn.
>>>>
>>>> The new code is
>>>> }else if(expression != null){
>>>>
>>>> ResultColumn col = null;
>>>> int i = 0;
>>>>
>>>> for(i = 0;
>>>> i < targetCols.size();
>>>> i ++){
>>>> col = targetCols.getOrderByColumn(i);
>>>> if(col != null &&
>>>> col.getExpression() == expression){
>>>> break;
>>>> }
>>>> }
>>>>
>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>> i <=
>>>> targetCols.size(); i++)".
>>>>
>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>> the
>>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>>> confusion has caught most of us at one time or another).
>>>>
>>>> The result is that when the sort key is an expression
>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>> list,
>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>> column in
>>>> the target list is orderable. This is usually not right. Consider the
>>>> following SQL:
>>>>
>>>> create table tblob( id int, b blob(1000));
>>>> select id,b from tblob order by abs(id);
>>>> select b,id from tblob order by abs(id);
>>>>
>>>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>> type". The second SELECT executes properly.
>>>>
>>>> 3. Testing. I would like to see some additional tests: the failing
>>>> case
>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>> separated
>>>> lists of ORDER BY expressions.
>>>>
>>>> Jack
>>>>
>>>>
>>>>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I have finished coding and testing in orderby.sql.
I'm not sure test is enough.
Would you please review it ?
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Satheesh Bandaram" <sa...@sourcery.org>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, March 12, 2005 6:59 AM
Subject: Re: About improvement of DERBY-134
> Hi Tomohito Nakayama,
>
> Just wanted to check how you are progressing on the patch update,
> following comments by myself and Jack. I do think you are working on an
> important enhancement that not only yourself but other developpers have
> expressed interest in. I strongly encourage you to continue working on
> this and post any questions or comments you might have. You are pretty
> close to addressing all issues.
>
> I am willing to help, if you need any, to continue taking this further.
>
> Satheesh
>
> TomohitoNakayama wrote:
>
>> Hello.
>> Thanks for your reviewing.
>>
>> About 1:
>> Handling any sortKey as expression is better structure.
>> A little challenging but worth for it.
>> I will try.
>>
>> About 2:
>> Uh oh.
>> Bug about starting value of element indexing in ResultColumnList ....
>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>> was needed.....
>>
>> About 3:
>> I see.
>> It seems that it is certainly needed to add test case .
>>
>> I will continue this issue.
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Sunday, February 20, 2005 8:37 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>> add some test pattern to orderby.sql.
>>>>
>>>> Would someone review patch please ?
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Sorry.
>>>>> Mistaken.
>>>>>
>>>>> LOOKAHEAD()....
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> Thank's for your reviewing.
>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>
>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>
>>>>>> #World is not simple as I wish to be.....
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>> To: Derby Development
>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>> I think the patch is a good start. But more work needs to be done.
>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>> (there may be more)
>>>>>>
>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
>>>>>> is written. Since orderby expression and orderby column can both
>>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>>> add lookup to avoid this.
>>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>>> from t1 order by i/2. So, needs more work.
>>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>> functionTests/tests/lang.
>>>>>> I do encourage you to continue work on this ...
>>>>>>
>>>>>> Satheesh
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>> I tried to solve DERBY-134.
>>>>>> Patch is attached to this mail.
>>>>>>
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>
>>>>>> Woops.
>>>>>> Mistaken.
>>>>>>
>>>>>>
>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: <de...@db.apache.org>
>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>> Subject: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello.
>>>>>> My name is Naka.
>>>>>> I'm very newbie in derby community.
>>>>>>
>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>> And found a interesting issue.
>>>>>>
>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>> clause.
>>>>>> #That title was difficult to understand a bit ....
>>>>>>
>>>>>> Solving this isn't useful?
>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>
>>>>>> What I think we need to do is as next:
>>>>>>
>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>>
>>> I have worked on Derby/Cloudscape for a few years and have even fixed
>>> one or two ORDER BY bugs in the past. I have reviewed your patch. It is
>>> close, but I have some problems with it.
>>>
>>> 1. sqlgrammar.jj. I think that creating a new method,
>>> isNonReservedKeyword() to determine whether a token is a non-reserved
>>> keyword or not, is a maintenance problem. Whenever we add a new
>>> non-reserved keyword we must add it to the list of tokens, to
>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>>> it in two places is difficult enough to discover or remember. If we need
>>> isNonReservedKeyword then we should find a way of combining
>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>> keeps the list of non-reserved key words.
>>>
>>> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
>>> key type. A column name is just one kind of <expression>. If the parser
>>> treats it as an expression we should still get the right ordering. I
>>> think that it would better if the parser did so. The OrderByColumn class
>>> can special case a simple column reference expression, as an
>>> optimization. This considerably simplifies parsing sort keys.
>>>
>>> The only sort key type that has to be handled specially is that of an
>>> integer constant. That specifies one of the select list columns as the
>>> sort key. This case can be recognized in the parser, as is done in the
>>> patch, or it can be recognized in OrderByColumn. In this alternative the
>>> parser always creates OrderByColumn nodes with the sort key given by an
>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>> whether the sort key expression is an integer constant, and if so treat
>>> it as a column position.
>>>
>>> The two alternatives differ in the way that they treat constant integer
>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
>>> an integer constant sort key expression as a result column position then
>>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>>> column, which I think is more usefull.
>>>
>>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>>> bindOrderByColumn method of class OrderByColumn.
>>>
>>> The new code is
>>> }else if(expression != null){
>>>
>>> ResultColumn col = null;
>>> int i = 0;
>>>
>>> for(i = 0;
>>> i < targetCols.size();
>>> i ++){
>>> col = targetCols.getOrderByColumn(i);
>>> if(col != null &&
>>> col.getExpression() == expression){
>>> break;
>>> }
>>> }
>>>
>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>> patch assumes 0 indexing. So the loop really should be "for( i = 1; i <=
>>> targetCols.size(); i++)".
>>>
>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of the
>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>> confusion has caught most of us at one time or another).
>>>
>>> The result is that when the sort key is an expression
>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target list,
>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>> OrderByColumn.bindOrderByColumn tests whether the second last column in
>>> the target list is orderable. This is usually not right. Consider the
>>> following SQL:
>>>
>>> create table tblob( id int, b blob(1000));
>>> select id,b from tblob order by abs(id);
>>> select b,id from tblob order by abs(id);
>>>
>>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>> type". The second SELECT executes properly.
>>>
>>> 3. Testing. I would like to see some additional tests: the failing case
>>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>>> the compiler handles ASC and DESC after a sort key, and comma separated
>>> lists of ORDER BY expressions.
>>>
>>> Jack
>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
>>>
>>>
>>
>>
>>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>
>
Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
I agree with Jeremy Boynes view that order by number should only
recognise simple numbers. I personnally think he has already provided a
good argument for that. If no one objects, I think the patch can proceed
assuming a simple number for order by.
Satheesh
TomohitoNakayama wrote:
> Hello.
>
> Sorry for my silence.
> I was in a little private trouble in these weeks.
>
> About for DERBY-134, I was at a loss how to treat column referenced by
> number.
>
> In point of view for implementation,
> it seem to be difficult to treat expression except for simple number
> as reference by number.
> I couldn't get value by getConstantValueAsObject() of BinaryOperatorNode.
>
> In point of view for specification, there exists topic which was
> written in mail of Jeremy Boynes .
> In addition to that, reference by number in order clause seems to be
> not recommended spec of SQL .
>
> I wonder allowing only simple number as reference to column may be
> reasonable spec.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Satheesh Bandaram"
> <sa...@sourcery.org>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Saturday, March 12, 2005 6:59 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> Hi Tomohito Nakayama,
>>
>> Just wanted to check how you are progressing on the patch update,
>> following comments by myself and Jack. I do think you are working on an
>> important enhancement that not only yourself but other developpers have
>> expressed interest in. I strongly encourage you to continue working on
>> this and post any questions or comments you might have. You are pretty
>> close to addressing all issues.
>>
>> I am willing to help, if you need any, to continue taking this further.
>>
>> Satheesh
>>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>> Thanks for your reviewing.
>>>
>>> About 1:
>>> Handling any sortKey as expression is better structure.
>>> A little challenging but worth for it.
>>> I will try.
>>>
>>> About 2:
>>> Uh oh.
>>> Bug about starting value of element indexing in ResultColumnList ....
>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>>> was needed.....
>>>
>>> About 3:
>>> I see.
>>> It seems that it is certainly needed to add test case .
>>>
>>> I will continue this issue.
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "Jack Klebanoff"
>>> <kl...@sbcglobal.net>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Sunday, February 20, 2005 8:37 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>>> add some test pattern to orderby.sql.
>>>>>
>>>>> Would someone review patch please ?
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Sorry.
>>>>>> Mistaken.
>>>>>>
>>>>>> LOOKAHEAD()....
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> Thank's for your reviewing.
>>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>>
>>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>>
>>>>>>> #World is not simple as I wish to be.....
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>>> To: Derby Development
>>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>> I think the patch is a good start. But more work needs to be done.
>>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>>> (there may be more)
>>>>>>>
>>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the
>>>>>>> patch
>>>>>>> is written. Since orderby expression and orderby column can both
>>>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>>>> add lookup to avoid this.
>>>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>>>> from t1 order by i/2. So, needs more work.
>>>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>>> functionTests/tests/lang.
>>>>>>> I do encourage you to continue work on this ...
>>>>>>>
>>>>>>> Satheesh
>>>>>>>
>>>>>>> TomohitoNakayama wrote:
>>>>>>>
>>>>>>> I tried to solve DERBY-134.
>>>>>>> Patch is attached to this mail.
>>>>>>>
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Woops.
>>>>>>> Mistaken.
>>>>>>>
>>>>>>>
>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>>> <to...@basil.ocn.ne.jp>
>>>>>>> To: <de...@db.apache.org>
>>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>>> Subject: About improvement of DERBY-134
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hello.
>>>>>>> My name is Naka.
>>>>>>> I'm very newbie in derby community.
>>>>>>>
>>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>>> And found a interesting issue.
>>>>>>>
>>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>>> sensitive way"
>>>>>>>
>>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>>> clause.
>>>>>>> #That title was difficult to understand a bit ....
>>>>>>>
>>>>>>> Solving this isn't useful?
>>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>>
>>>>>>> What I think we need to do is as next:
>>>>>>>
>>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> /*
>>>>>>>
>>>>>>> Tomohito Nakayama
>>>>>>> tomoihto@rose.zero.ad.jp
>>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>>
>>>>>>> Naka
>>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>>
>>>>>>> */
>>>>>>>
>>>> I have worked on Derby/Cloudscape for a few years and have even fixed
>>>> one or two ORDER BY bugs in the past. I have reviewed your patch.
>>>> It is
>>>> close, but I have some problems with it.
>>>>
>>>> 1. sqlgrammar.jj. I think that creating a new method,
>>>> isNonReservedKeyword() to determine whether a token is a non-reserved
>>>> keyword or not, is a maintenance problem. Whenever we add a new
>>>> non-reserved keyword we must add it to the list of tokens, to
>>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>>>> it in two places is difficult enough to discover or remember. If we
>>>> need
>>>> isNonReservedKeyword then we should find a way of combining
>>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>>> keeps the list of non-reserved key words.
>>>>
>>>> It is not necessary for the parser to recognize 3 cases of ORDER BY
>>>> sort
>>>> key type. A column name is just one kind of <expression>. If the
>>>> parser
>>>> treats it as an expression we should still get the right ordering. I
>>>> think that it would better if the parser did so. The OrderByColumn
>>>> class
>>>> can special case a simple column reference expression, as an
>>>> optimization. This considerably simplifies parsing sort keys.
>>>>
>>>> The only sort key type that has to be handled specially is that of an
>>>> integer constant. That specifies one of the select list columns as the
>>>> sort key. This case can be recognized in the parser, as is done in the
>>>> patch, or it can be recognized in OrderByColumn. In this
>>>> alternative the
>>>> parser always creates OrderByColumn nodes with the sort key given
>>>> by an
>>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>>> whether the sort key expression is an integer constant, and if so
>>>> treat
>>>> it as a column position.
>>>>
>>>> The two alternatives differ in the way that they treat constant
>>>> integer
>>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC"
>>>> and
>>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn
>>>> treated
>>>> an integer constant sort key expression as a result column position
>>>> then
>>>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>>>> column, which I think is more usefull.
>>>>
>>>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>>>> bindOrderByColumn method of class OrderByColumn.
>>>>
>>>> The new code is
>>>> }else if(expression != null){
>>>>
>>>> ResultColumn col = null;
>>>> int i = 0;
>>>>
>>>> for(i = 0;
>>>> i < targetCols.size();
>>>> i ++){
>>>> col = targetCols.getOrderByColumn(i);
>>>> if(col != null &&
>>>> col.getExpression() == expression){
>>>> break;
>>>> }
>>>> }
>>>>
>>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>>> patch assumes 0 indexing. So the loop really should be "for( i = 1;
>>>> i <=
>>>> targetCols.size(); i++)".
>>>>
>>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of
>>>> the
>>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>>> confusion has caught most of us at one time or another).
>>>>
>>>> The result is that when the sort key is an expression
>>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target
>>>> list,
>>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>>> OrderByColumn.bindOrderByColumn tests whether the second last
>>>> column in
>>>> the target list is orderable. This is usually not right. Consider the
>>>> following SQL:
>>>>
>>>> create table tblob( id int, b blob(1000));
>>>> select id,b from tblob order by abs(id);
>>>> select b,id from tblob order by abs(id);
>>>>
>>>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>>> type". The second SELECT executes properly.
>>>>
>>>> 3. Testing. I would like to see some additional tests: the failing
>>>> case
>>>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>>>> the compiler handles ASC and DESC after a sort key, and comma
>>>> separated
>>>> lists of ORDER BY expressions.
>>>>
>>>> Jack
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>>
>>
>
>
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Sorry for my silence.
I was in a little private trouble in these weeks.
About for DERBY-134, I was at a loss how to treat column referenced by
number.
In point of view for implementation,
it seem to be difficult to treat expression except for simple number as
reference by number.
I couldn't get value by getConstantValueAsObject() of BinaryOperatorNode.
In point of view for specification, there exists topic which was written in
mail of Jeremy Boynes .
In addition to that, reference by number in order clause seems to be not
recommended spec of SQL .
I wonder allowing only simple number as reference to column may be
reasonable spec.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Satheesh Bandaram" <sa...@sourcery.org>
To: "Derby Development" <de...@db.apache.org>
Sent: Saturday, March 12, 2005 6:59 AM
Subject: Re: About improvement of DERBY-134
> Hi Tomohito Nakayama,
>
> Just wanted to check how you are progressing on the patch update,
> following comments by myself and Jack. I do think you are working on an
> important enhancement that not only yourself but other developpers have
> expressed interest in. I strongly encourage you to continue working on
> this and post any questions or comments you might have. You are pretty
> close to addressing all issues.
>
> I am willing to help, if you need any, to continue taking this further.
>
> Satheesh
>
> TomohitoNakayama wrote:
>
>> Hello.
>> Thanks for your reviewing.
>>
>> About 1:
>> Handling any sortKey as expression is better structure.
>> A little challenging but worth for it.
>> I will try.
>>
>> About 2:
>> Uh oh.
>> Bug about starting value of element indexing in ResultColumnList ....
>> Test of comma separated lists of ORDER BY expressions in orderby.sql
>> was needed.....
>>
>> About 3:
>> I see.
>> It seems that it is certainly needed to add test case .
>>
>> I will continue this issue.
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "Jack Klebanoff"
>> <kl...@sbcglobal.net>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Sunday, February 20, 2005 8:37 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> TomohitoNakayama wrote:
>>>
>>>> Hello.
>>>>
>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>>> add some test pattern to orderby.sql.
>>>>
>>>> Would someone review patch please ?
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Sunday, February 13, 2005 4:09 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Sorry.
>>>>> Mistaken.
>>>>>
>>>>> LOOKAHEAD()....
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>> Hello.
>>>>>>
>>>>>> Thank's for your reviewing.
>>>>>> Grammer ambiguity is very critical problem ....
>>>>>>
>>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>>
>>>>>> #World is not simple as I wish to be.....
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>>> To: Derby Development
>>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>> I think the patch is a good start. But more work needs to be done.
>>>>>> Based on a quick review, some of the items to be completed are:
>>>>>> (there may be more)
>>>>>>
>>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
>>>>>> is written. Since orderby expression and orderby column can both
>>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>>> add lookup to avoid this.
>>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>>> from t1 order by i/2. So, needs more work.
>>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>>> could add test cases to orderby.sql test that is already part of
>>>>>> functionTests/tests/lang.
>>>>>> I do encourage you to continue work on this ...
>>>>>>
>>>>>> Satheesh
>>>>>>
>>>>>> TomohitoNakayama wrote:
>>>>>>
>>>>>> I tried to solve DERBY-134.
>>>>>> Patch is attached to this mail.
>>>>>>
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>>> Subject: Re: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>
>>>>>> Woops.
>>>>>> Mistaken.
>>>>>>
>>>>>>
>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>>
>>>>>>
>>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>>> <to...@basil.ocn.ne.jp>
>>>>>> To: <de...@db.apache.org>
>>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>>> Subject: About improvement of DERBY-134
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello.
>>>>>> My name is Naka.
>>>>>> I'm very newbie in derby community.
>>>>>>
>>>>>> I'm now seeing report for derby in ASF Jira.
>>>>>> And found a interesting issue.
>>>>>>
>>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>>> sensitive way"
>>>>>>
>>>>>> This issue seems to mean that we can't use complex item in order
>>>>>> clause.
>>>>>> #That title was difficult to understand a bit ....
>>>>>>
>>>>>> Solving this isn't useful?
>>>>>> Especially when we manipulate DBMS by hand.
>>>>>>
>>>>>> What I think we need to do is as next:
>>>>>>
>>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> /*
>>>>>>
>>>>>> Tomohito Nakayama
>>>>>> tomoihto@rose.zero.ad.jp
>>>>>> tomonaka@basil.ocn.ne.jp
>>>>>>
>>>>>> Naka
>>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>>
>>>>>> */
>>>>>>
>>> I have worked on Derby/Cloudscape for a few years and have even fixed
>>> one or two ORDER BY bugs in the past. I have reviewed your patch. It is
>>> close, but I have some problems with it.
>>>
>>> 1. sqlgrammar.jj. I think that creating a new method,
>>> isNonReservedKeyword() to determine whether a token is a non-reserved
>>> keyword or not, is a maintenance problem. Whenever we add a new
>>> non-reserved keyword we must add it to the list of tokens, to
>>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>>> it in two places is difficult enough to discover or remember. If we need
>>> isNonReservedKeyword then we should find a way of combining
>>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>>> keeps the list of non-reserved key words.
>>>
>>> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
>>> key type. A column name is just one kind of <expression>. If the parser
>>> treats it as an expression we should still get the right ordering. I
>>> think that it would better if the parser did so. The OrderByColumn class
>>> can special case a simple column reference expression, as an
>>> optimization. This considerably simplifies parsing sort keys.
>>>
>>> The only sort key type that has to be handled specially is that of an
>>> integer constant. That specifies one of the select list columns as the
>>> sort key. This case can be recognized in the parser, as is done in the
>>> patch, or it can be recognized in OrderByColumn. In this alternative the
>>> parser always creates OrderByColumn nodes with the sort key given by an
>>> expression (a ValueNode). At bind time OrderByColumn can determine
>>> whether the sort key expression is an integer constant, and if so treat
>>> it as a column position.
>>>
>>> The two alternatives differ in the way that they treat constant integer
>>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
>>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
>>> an integer constant sort key expression as a result column position then
>>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>>> column, which I think is more usefull.
>>>
>>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>>> bindOrderByColumn method of class OrderByColumn.
>>>
>>> The new code is
>>> }else if(expression != null){
>>>
>>> ResultColumn col = null;
>>> int i = 0;
>>>
>>> for(i = 0;
>>> i < targetCols.size();
>>> i ++){
>>> col = targetCols.getOrderByColumn(i);
>>> if(col != null &&
>>> col.getExpression() == expression){
>>> break;
>>> }
>>> }
>>>
>>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>>> patch assumes 0 indexing. So the loop really should be "for( i = 1; i <=
>>> targetCols.size(); i++)".
>>>
>>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of the
>>> Derby code use 0 indexing while others use 1 indexing. The resulting
>>> confusion has caught most of us at one time or another).
>>>
>>> The result is that when the sort key is an expression
>>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target list,
>>> but OrderByColumn.bindOrderByColumn doesn't find it.
>>> OrderByColumn.bindOrderByColumn tests whether the second last column in
>>> the target list is orderable. This is usually not right. Consider the
>>> following SQL:
>>>
>>> create table tblob( id int, b blob(1000));
>>> select id,b from tblob order by abs(id);
>>> select b,id from tblob order by abs(id);
>>>
>>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>>> EXCEPT or DISTINCT, because comparisons are not supported for that
>>> type". The second SELECT executes properly.
>>>
>>> 3. Testing. I would like to see some additional tests: the failing case
>>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>>> the compiler handles ASC and DESC after a sort key, and comma separated
>>> lists of ORDER BY expressions.
>>>
>>> Jack
>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
>>>
>>>
>>
>>
>>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@sourcery.org>.
Hi Tomohito Nakayama,
Just wanted to check how you are progressing on the patch update,
following comments by myself and Jack. I do think you are working on an
important enhancement that not only yourself but other developpers have
expressed interest in. I strongly encourage you to continue working on
this and post any questions or comments you might have. You are pretty
close to addressing all issues.
I am willing to help, if you need any, to continue taking this further.
Satheesh
TomohitoNakayama wrote:
> Hello.
> Thanks for your reviewing.
>
> About 1:
> Handling any sortKey as expression is better structure.
> A little challenging but worth for it.
> I will try.
>
> About 2:
> Uh oh.
> Bug about starting value of element indexing in ResultColumnList ....
> Test of comma separated lists of ORDER BY expressions in orderby.sql
> was needed.....
>
> About 3:
> I see.
> It seems that it is certainly needed to add test case .
>
> I will continue this issue.
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "Jack Klebanoff"
> <kl...@sbcglobal.net>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Sunday, February 20, 2005 8:37 AM
> Subject: Re: About improvement of DERBY-134
>
>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I have put some LOOKAHEAD to sqlgrammer.jj and
>>> add some test pattern to orderby.sql.
>>>
>>> Would someone review patch please ?
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Sunday, February 13, 2005 4:09 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Sorry.
>>>> Mistaken.
>>>>
>>>> LOOKAHEAD()....
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Sunday, February 13, 2005 3:42 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>> Hello.
>>>>>
>>>>> Thank's for your reviewing.
>>>>> Grammer ambiguity is very critical problem ....
>>>>>
>>>>> I will try to put LOOKUP() and consider about testing..
>>>>>
>>>>> #World is not simple as I wish to be.....
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>>> To: Derby Development
>>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>> I think the patch is a good start. But more work needs to be done.
>>>>> Based on a quick review, some of the items to be completed are:
>>>>> (there may be more)
>>>>>
>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
>>>>> is written. Since orderby expression and orderby column can both
>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>>> add lookup to avoid this.
>>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>>> from t1 order by i/2. So, needs more work.
>>>>> Add more test cases and test outputs to show changed behavior. You
>>>>> could add test cases to orderby.sql test that is already part of
>>>>> functionTests/tests/lang.
>>>>> I do encourage you to continue work on this ...
>>>>>
>>>>> Satheesh
>>>>>
>>>>> TomohitoNakayama wrote:
>>>>>
>>>>> I tried to solve DERBY-134.
>>>>> Patch is attached to this mail.
>>>>>
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: "Derby Development" <de...@db.apache.org>
>>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>>> Subject: Re: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>
>>>>> Woops.
>>>>> Mistaken.
>>>>>
>>>>>
>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>> sensitive way"
>>>>>
>>>>>
>>>>>
>>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>>> sensitive way"
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>>> <to...@basil.ocn.ne.jp>
>>>>> To: <de...@db.apache.org>
>>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>>> Subject: About improvement of DERBY-134
>>>>>
>>>>>
>>>>>
>>>>> Hello.
>>>>> My name is Naka.
>>>>> I'm very newbie in derby community.
>>>>>
>>>>> I'm now seeing report for derby in ASF Jira.
>>>>> And found a interesting issue.
>>>>>
>>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>>> sensitive way"
>>>>>
>>>>> This issue seems to mean that we can't use complex item in order
>>>>> clause.
>>>>> #That title was difficult to understand a bit ....
>>>>>
>>>>> Solving this isn't useful?
>>>>> Especially when we manipulate DBMS by hand.
>>>>>
>>>>> What I think we need to do is as next:
>>>>>
>>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>>> Make OrderByColumn class to support additiveExpression.
>>>>>
>>>>> Best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> tomoihto@rose.zero.ad.jp
>>>>> tomonaka@basil.ocn.ne.jp
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>>
>> I have worked on Derby/Cloudscape for a few years and have even fixed
>> one or two ORDER BY bugs in the past. I have reviewed your patch. It is
>> close, but I have some problems with it.
>>
>> 1. sqlgrammar.jj. I think that creating a new method,
>> isNonReservedKeyword() to determine whether a token is a non-reserved
>> keyword or not, is a maintenance problem. Whenever we add a new
>> non-reserved keyword we must add it to the list of tokens, to
>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>> it in two places is difficult enough to discover or remember. If we need
>> isNonReservedKeyword then we should find a way of combining
>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>> keeps the list of non-reserved key words.
>>
>> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
>> key type. A column name is just one kind of <expression>. If the parser
>> treats it as an expression we should still get the right ordering. I
>> think that it would better if the parser did so. The OrderByColumn class
>> can special case a simple column reference expression, as an
>> optimization. This considerably simplifies parsing sort keys.
>>
>> The only sort key type that has to be handled specially is that of an
>> integer constant. That specifies one of the select list columns as the
>> sort key. This case can be recognized in the parser, as is done in the
>> patch, or it can be recognized in OrderByColumn. In this alternative the
>> parser always creates OrderByColumn nodes with the sort key given by an
>> expression (a ValueNode). At bind time OrderByColumn can determine
>> whether the sort key expression is an integer constant, and if so treat
>> it as a column position.
>>
>> The two alternatives differ in the way that they treat constant integer
>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
>> an integer constant sort key expression as a result column position then
>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>> column, which I think is more usefull.
>>
>> 2. OrderByColumn. I think that there is a mistake in the patch to the
>> bindOrderByColumn method of class OrderByColumn.
>>
>> The new code is
>> }else if(expression != null){
>>
>> ResultColumn col = null;
>> int i = 0;
>>
>> for(i = 0;
>> i < targetCols.size();
>> i ++){
>> col = targetCols.getOrderByColumn(i);
>> if(col != null &&
>> col.getExpression() == expression){
>> break;
>> }
>> }
>>
>> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
>> patch assumes 0 indexing. So the loop really should be "for( i = 1; i <=
>> targetCols.size(); i++)".
>>
>> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of the
>> Derby code use 0 indexing while others use 1 indexing. The resulting
>> confusion has caught most of us at one time or another).
>>
>> The result is that when the sort key is an expression
>> OrderByColumn.pullUpOrderByColumn adds it to the end of the target list,
>> but OrderByColumn.bindOrderByColumn doesn't find it.
>> OrderByColumn.bindOrderByColumn tests whether the second last column in
>> the target list is orderable. This is usually not right. Consider the
>> following SQL:
>>
>> create table tblob( id int, b blob(1000));
>> select id,b from tblob order by abs(id);
>> select b,id from tblob order by abs(id);
>>
>> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
>> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
>> EXCEPT or DISTINCT, because comparisons are not supported for that
>> type". The second SELECT executes properly.
>>
>> 3. Testing. I would like to see some additional tests: the failing case
>> above; ORDER BY expressions combined with ASC and DESC, to ensure that
>> the compiler handles ASC and DESC after a sort key, and comma separated
>> lists of ORDER BY expressions.
>>
>> Jack
>>
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
>>
>>
>
>
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thanks for your reviewing.
About 1:
Handling any sortKey as expression is better structure.
A little challenging but worth for it.
I will try.
About 2:
Uh oh.
Bug about starting value of element indexing in ResultColumnList ....
Test of comma separated lists of ORDER BY expressions in orderby.sql was
needed.....
About 3:
I see.
It seems that it is certainly needed to add test case .
I will continue this issue.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Jack Klebanoff" <kl...@sbcglobal.net>
To: "Derby Development" <de...@db.apache.org>
Sent: Sunday, February 20, 2005 8:37 AM
Subject: Re: About improvement of DERBY-134
> TomohitoNakayama wrote:
>
>> Hello.
>>
>> I have put some LOOKAHEAD to sqlgrammer.jj and
>> add some test pattern to orderby.sql.
>>
>> Would someone review patch please ?
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Sunday, February 13, 2005 4:09 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Sorry.
>>> Mistaken.
>>>
>>> LOOKAHEAD()....
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Sunday, February 13, 2005 3:42 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>> Hello.
>>>>
>>>> Thank's for your reviewing.
>>>> Grammer ambiguity is very critical problem ....
>>>>
>>>> I will try to put LOOKUP() and consider about testing..
>>>>
>>>> #World is not simple as I wish to be.....
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: Satheesh Bandaram
>>>> To: Derby Development
>>>> Sent: Saturday, February 12, 2005 4:10 AM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>> I think the patch is a good start. But more work needs to be done.
>>>> Based on a quick review, some of the items to be completed are:
>>>> (there may be more)
>>>>
>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
>>>> is written. Since orderby expression and orderby column can both
>>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>>> add lookup to avoid this.
>>>> Current patch doesn't seem to support all expressions, Ex: select i
>>>> from t1 order by i/2. So, needs more work.
>>>> Add more test cases and test outputs to show changed behavior. You
>>>> could add test cases to orderby.sql test that is already part of
>>>> functionTests/tests/lang.
>>>> I do encourage you to continue work on this ...
>>>>
>>>> Satheesh
>>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>> I tried to solve DERBY-134.
>>>> Patch is attached to this mail.
>>>>
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: "Derby Development" <de...@db.apache.org>
>>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>>> Subject: Re: About improvement of DERBY-134
>>>>
>>>>
>>>>
>>>> Woops.
>>>> Mistaken.
>>>>
>>>>
>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>> sensitive way"
>>>>
>>>>
>>>>
>>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>>> sensitive way"
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>> ----- Original Message ----- From: "TomohitoNakayama"
>>>> <to...@basil.ocn.ne.jp>
>>>> To: <de...@db.apache.org>
>>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>>> Subject: About improvement of DERBY-134
>>>>
>>>>
>>>>
>>>> Hello.
>>>> My name is Naka.
>>>> I'm very newbie in derby community.
>>>>
>>>> I'm now seeing report for derby in ASF Jira.
>>>> And found a interesting issue.
>>>>
>>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>>> sensitive way"
>>>>
>>>> This issue seems to mean that we can't use complex item in order
>>>> clause.
>>>> #That title was difficult to understand a bit ....
>>>>
>>>> Solving this isn't useful?
>>>> Especially when we manipulate DBMS by hand.
>>>>
>>>> What I think we need to do is as next:
>>>>
>>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>>> Make OrderByColumn class to support additiveExpression.
>>>>
>>>> Best regards.
>>>>
>>>> /*
>>>>
>>>> Tomohito Nakayama
>>>> tomoihto@rose.zero.ad.jp
>>>> tomonaka@basil.ocn.ne.jp
>>>>
>>>> Naka
>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>
>>>> */
>>>>
> I have worked on Derby/Cloudscape for a few years and have even fixed
> one or two ORDER BY bugs in the past. I have reviewed your patch. It is
> close, but I have some problems with it.
>
> 1. sqlgrammar.jj. I think that creating a new method,
> isNonReservedKeyword() to determine whether a token is a non-reserved
> keyword or not, is a maintenance problem. Whenever we add a new
> non-reserved keyword we must add it to the list of tokens, to
> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
> it in two places is difficult enough to discover or remember. If we need
> isNonReservedKeyword then we should find a way of combining
> nonReservedKeyword and isNonReservedKeyword so that only one of them
> keeps the list of non-reserved key words.
>
> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
> key type. A column name is just one kind of <expression>. If the parser
> treats it as an expression we should still get the right ordering. I
> think that it would better if the parser did so. The OrderByColumn class
> can special case a simple column reference expression, as an
> optimization. This considerably simplifies parsing sort keys.
>
> The only sort key type that has to be handled specially is that of an
> integer constant. That specifies one of the select list columns as the
> sort key. This case can be recognized in the parser, as is done in the
> patch, or it can be recognized in OrderByColumn. In this alternative the
> parser always creates OrderByColumn nodes with the sort key given by an
> expression (a ValueNode). At bind time OrderByColumn can determine
> whether the sort key expression is an integer constant, and if so treat
> it as a column position.
>
> The two alternatives differ in the way that they treat constant integer
> expressions like "ORDER BY 2-1". The patch orders the rows by the
> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
> an integer constant sort key expression as a result column position then
> "ORDER BY 2-1" would cause the rows to be ordered on the first result
> column, which I think is more usefull.
>
> 2. OrderByColumn. I think that there is a mistake in the patch to the
> bindOrderByColumn method of class OrderByColumn.
>
> The new code is
> }else if(expression != null){
>
> ResultColumn col = null;
> int i = 0;
>
> for(i = 0;
> i < targetCols.size();
> i ++){
> col = targetCols.getOrderByColumn(i);
> if(col != null &&
> col.getExpression() == expression){
> break;
> }
> }
>
> Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
> patch assumes 0 indexing. So the loop really should be "for( i = 1; i <=
> targetCols.size(); i++)".
>
> (Java likes 0 indexing while SQL likes 1 indexing. So some parts of the
> Derby code use 0 indexing while others use 1 indexing. The resulting
> confusion has caught most of us at one time or another).
>
> The result is that when the sort key is an expression
> OrderByColumn.pullUpOrderByColumn adds it to the end of the target list,
> but OrderByColumn.bindOrderByColumn doesn't find it.
> OrderByColumn.bindOrderByColumn tests whether the second last column in
> the target list is orderable. This is usually not right. Consider the
> following SQL:
>
> create table tblob( id int, b blob(1000));
> select id,b from tblob order by abs(id);
> select b,id from tblob order by abs(id);
>
> The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
> may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
> EXCEPT or DISTINCT, because comparisons are not supported for that
> type". The second SELECT executes properly.
>
> 3. Testing. I would like to see some additional tests: the failing case
> above; ORDER BY expressions combined with ASC and DESC, to ensure that
> the compiler handles ASC and DESC after a sort key, and comma separated
> lists of ORDER BY expressions.
>
> Jack
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2005/02/18
Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Also, if we disallow C1/C1, how about (C1+C2)/(C2+C1)? Same question for
(C1+C1)/2*C1. How intelligent do we need to make this thing? I still
vote for the simplest approach, proposed by Jeremy. I also tried this on
DB2 that I have access to. This what is proposed by Tomohito and Jeremy
matches that behaviour.
Satheesh
db2 => select * from t
I J
----------- -----------
1 1
2 2
0 4
5 0
db2 => select * from t order by 1+1
I J
----------- -----------
1 1
2 2
0 4
5 0
db2 => select * from t order by 2
I J
----------- -----------
5 0
1 1
2 2
0 4
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>
>>
> > If it made it clearer I would prefer that a compilation error is
> raised
>
>> for order by expressions that do resolve to constants, since supporting
>> them adds no value. How this error would be raised I'm not sure about.
>>
>> ORDER BY 1 - ok (column position 1)
>> ORDER BY C1 - ok
>> ORDER BY FN(C1) - ok
>> ORDER BY 1 + 1 - disallow
>> ORDER BY C1/C1 - disallow
>>
>
> The spec says that the sort keys are value expressions which would
> make both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't
> raise an error.
>
> In both cases the result is implementation dependent as the key will
> be the same for all rows. I think /choosing/ to define the result when
> the value expression is a simple integer literal is useful so we can
> support the "ORDER BY 1,2" syntax common on other platforms; I believe
> anything more complex than that is going to be confusing.
>
> This may make the parser more complex, but that's a development issue
> not a user one :-)
>
> --
> Jeremy
>
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Soory.
Mistaken.
> Q1:
> What is "generated names" ?
> <"> "SQLCol NUMBER" <"> seems to be called "generated names".
Q1:
What is "generated names" ?
<"> "SQLCol" NUMBER <"> seems to be called "generated names".
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Monday, March 14, 2005 2:36 AM
Subject: Re: About improvement of DERBY-134
> Hello.
>
> I tried to change handling single column name in order by clause , and
> just finished coding.
> Now single column name is treated as additiveExpression in afterPatch.
>
> And I have found next difference in orderby.out between beforePatch and
> afterPatch as follows.
> I 'm confusing whether I should judge this is bug or not.
>
> beforePatch
> ij> -- . order by doesn't see generated names
> values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
> 1 |2 |3
> -----------------------------------
> 1 |0 |1
> 1 |0 |0
> 0 |0 |1
> 0 |1 |0
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
> ERROR 42X78: Column 'SQLCol1' is not in the result of the query
> expression.
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
> ERROR 42X78: Column 'SQLCol2' is not in the result of the query
> expression.
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
> 1 |2 |3
> -----------------------------------
> 0 |0 |1
> 0 |1 |0
> 1 |0 |0
> 1 |0 |1
>
> afterPatch
> ij> -- . order by doesn't see generated names ....?
> values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
> 1 |2 |3
> -----------------------------------
> 1 |0 |1
> 1 |0 |0
> 0 |0 |1
> 0 |1 |0
>>-- now next was accepted.
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
> 1 |2 |3
> -----------------------------------
> 0 |1 |0
> 0 |0 |1
> 1 |0 |0
> 1 |0 |1
>>-- now next was accepted too.
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
> 1 |2 |3
> -----------------------------------
> 0 |0 |1
> 1 |0 |0
> 1 |0 |1
> 0 |1 |0
> ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
> 1 |2 |3
> -----------------------------------
> 0 |0 |1
> 0 |1 |0
> 1 |0 |0
> 1 |0 |1
>
> I have some question now.
>
> Q1:
> What is "generated names" ?
> <"> "SQLCol NUMBER" <"> seems to be called "generated names".
>
> Q2:
> Why was it error to use "generated name" in order by caluse as seen in
> beforePatch?
>
> Q3:
> Is it bug to accept "generated names" in order clause like as in
> afterPatcch ?
>
> Please give me some adivise...
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Thanks Satheesh.
It seems that I could address this phenomena evaluating
resultCol.isNameGenerated() in OrderByColumn.bindOrderByColumn.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: Satheesh Bandaram
To: Derby Development
Sent: Monday, March 14, 2005 2:53 AM
Subject: Re: About improvement of DERBY-134
I think new behavior is a bug... and should be addressed in the patch.
Since there is no column name called 'SQLCol1' in the user querry, accepting
an order by with that name is incorrect. Column names like these are
generated names when there is no exposed name or alias provided for the
result columns. Derby generates these names and should be hidden to the end
user.
It should be easy to address this. You probably need to mark any new
expressions you are adding as generated columns using setNameGenerated(true)
call.
Satheesh
TomohitoNakayama wrote:
Hello.
I tried to change handling single column name in order by clause , and
just finished coding.
Now single column name is treated as additiveExpression in afterPatch.
And I have found next difference in orderby.out between beforePatch and
afterPatch as follows.
I 'm confusing whether I should judge this is bug or not.
beforePatch
ij> -- . order by doesn't see generated names
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
1 |2 |3
-----------------------------------
1 |0 |1
1 |0 |0
0 |0 |1
0 |1 |0
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
ERROR 42X78: Column 'SQLCol1' is not in the result of the query
expression.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
ERROR 42X78: Column 'SQLCol2' is not in the result of the query
expression.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
1 |2 |3
-----------------------------------
0 |0 |1
0 |1 |0
1 |0 |0
1 |0 |1
afterPatch
ij> -- . order by doesn't see generated names ....?
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
1 |2 |3
-----------------------------------
1 |0 |1
1 |0 |0
0 |0 |1
0 |1 |0
-- now next was accepted.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
1 |2 |3
-----------------------------------
0 |1 |0
0 |0 |1
1 |0 |0
1 |0 |1
-- now next was accepted too.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
1 |2 |3
-----------------------------------
0 |0 |1
1 |0 |0
1 |0 |1
0 |1 |0
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
1 |2 |3
-----------------------------------
0 |0 |1
0 |1 |0
1 |0 |0
1 |0 |1
I have some question now.
Q1:
What is "generated names" ?
<"> "SQLCol NUMBER" <"> seems to be called "generated names".
Q2:
Why was it error to use "generated name" in order by caluse as seen in
beforePatch?
Q3:
Is it bug to accept "generated names" in order clause like as in
afterPatcch ?
Please give me some adivise...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> Not sure what you mean by *the case where you are using VALUES to construct a
> table*, Derby does allow naming those columns.
>
> ij> values (1,1,1), (2,2,2);
> 1 |2 |3
> -----------------------------------
> 1 |1 |1
> 2 |2 |2
> ij> select * from (values (1,1,1), (2,2,2)) as t(i,j,k) order by i desc;
> I |J |K
> -----------------------------------
> 2 |2 |2
> 1 |1 |1
>
> Aren't these symantically the same?
>
As I read it they are close but a little different.
The first is simply constructing a table and as such the columns would
have implementation dependent names; the second is constucting a table
the same way (again with implementation dependent names) but as a table
subquery with a derived column list that defines the column names for
use in the outer select.
The second provides a portable (ok, conforming) way of naming the
columns. To do the same thing the first way we would need to support
values (1,1,1), (2,2,2) order by "SQLCol1" desc
in the same way as
ij> select "SQLCol3" from ( values(1,2,3),(4,5,6)) as t order by
"SQLCol3" desc;
SQLCol3
-----------
6
3
works now.
--
Jeremy
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> Derby actually generates two different names... 1) Unique name for
> unnamed references 2) Final exposed names for top level unnamed result
> columns. The unique names are of the form 'SQLCol<Number>' and final
> exposed names, that IJ shows, are of the form '<Number>'. The number
> part of the names could be different. (Eg: 'SQLCol5' may map to '1' as
> exposed name)
>
> The SQLCol unique names can't be guessed correctly by end users. It may
> change depending on how the query is compiled and can change totally
> unexpectedly.(Like adding an extra union at the end of the query could
> change top level result column names) So these are definitely not
> suitable to be used by end users. It may be possible to use final
> exposed names (like '1', '2') in order by clause, but Derby currently
> doesn't allow it. It is not consistant to allow this only under some new
> code path, as a side effect. We have to consistantly change it all over.
> I don't know what the SQL standard says about this... I don't want to
> look at that huge spec on a Sunday. :-)
>
> I am not sure we should, even if we could... Like you said, these
> numbers are implementation dependent, change from one vendor to another
> and may even change from one release to another. Shouldn't querries
> instead use explicit aliasing to avoid all confusion, which is standards
> based and portable?
>
Yes they should. Unfortunately that is not always possible and I think
the case where you are using VALUES to construct a table is one of
those. In other words, Tomohito's test is reliant on implementation
dependent behaviour.
The spec does say that alias names are generated and so it should be
possible to reference them even if doing so is non-portable. Personally
I would prefer the <SQLCol1> form because it is at least a legal
identifier; using <1> would mean having to quote the reference which
seems inconvenient and confusing e.g. ORDER BY "1"
Whatever the outcome I do think we need to document how the names are
generated so a user can figure it out.
--
Jeremy
Re: About improvement of DERBY-134
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Derby actually generates two different names... 1) Unique name for
unnamed references 2) Final exposed names for top level unnamed result
columns. The unique names are of the form 'SQLCol<Number>' and final
exposed names, that IJ shows, are of the form '<Number>'. The number
part of the names could be different. (Eg: 'SQLCol5' may map to '1' as
exposed name)
The SQLCol unique names can't be guessed correctly by end users. It may
change depending on how the query is compiled and can change totally
unexpectedly.(Like adding an extra union at the end of the query could
change top level result column names) So these are definitely not
suitable to be used by end users. It may be possible to use final
exposed names (like '1', '2') in order by clause, but Derby currently
doesn't allow it. It is not consistant to allow this only under some new
code path, as a side effect. We have to consistantly change it all over.
I don't know what the SQL standard says about this... I don't want to
look at that huge spec on a Sunday. :-)
I am not sure we should, even if we could... Like you said, these
numbers are implementation dependent, change from one vendor to another
and may even change from one release to another. Shouldn't querries
instead use explicit aliasing to avoid all confusion, which is standards
based and portable?
Satheesh
Jeremy Boynes wrote
> I'm not so sure - I thought expressions were given implementation
> dependent names that could be referenced in a sort key. In our case
> the name is "SQLCol1" so referencing that would be valid but
> non-portable.
>
> I'm curious why ij is not labeling the columns that way and whether it
> should.
>
> --
> Jeremy
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Satheesh Bandaram wrote:
> I think new behavior is a bug... and should be addressed in the patch. Since
> there is no column name called 'SQLCol1' in the user querry, accepting an order
> by with that name is incorrect. Column names like these are generated names when
> there is no exposed name or alias provided for the result columns. Derby
> generates these names and should be hidden to the end user.
>
> It should be easy to address this. You probably need to mark any new expressions
> you are adding as generated columns using* setNameGenerated(true)* call.
>
I'm not so sure - I thought expressions were given implementation
dependent names that could be referenced in a sort key. In our case the
name is "SQLCol1" so referencing that would be valid but non-portable.
I'm curious why ij is not labeling the columns that way and whether it
should.
--
Jeremy
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I tried to change handling single column name in order by clause , and just
finished coding.
Now single column name is treated as additiveExpression in afterPatch.
And I have found next difference in orderby.out between beforePatch and
afterPatch as follows.
I 'm confusing whether I should judge this is bug or not.
beforePatch
ij> -- . order by doesn't see generated names
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
1 |2 |3
-----------------------------------
1 |0 |1
1 |0 |0
0 |0 |1
0 |1 |0
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
ERROR 42X78: Column 'SQLCol1' is not in the result of the query expression.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
ERROR 42X78: Column 'SQLCol2' is not in the result of the query expression.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
1 |2 |3
-----------------------------------
0 |0 |1
0 |1 |0
1 |0 |0
1 |0 |1
afterPatch
ij> -- . order by doesn't see generated names ....?
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
1 |2 |3
-----------------------------------
1 |0 |1
1 |0 |0
0 |0 |1
0 |1 |0
>-- now next was accepted.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
1 |2 |3
-----------------------------------
0 |1 |0
0 |0 |1
1 |0 |0
1 |0 |1
>-- now next was accepted too.
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
1 |2 |3
-----------------------------------
0 |0 |1
1 |0 |0
1 |0 |1
0 |1 |0
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
1 |2 |3
-----------------------------------
0 |0 |1
0 |1 |0
1 |0 |0
1 |0 |1
I have some question now.
Q1:
What is "generated names" ?
<"> "SQLCol NUMBER" <"> seems to be called "generated names".
Q2:
Why was it error to use "generated name" in order by caluse as seen in
beforePatch?
Q3:
Is it bug to accept "generated names" in order clause like as in afterPatcch
?
Please give me some adivise...
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 2005/03/11
Re: About improvement of DERBY-134
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jeremy Boynes wrote:
> The spec says that the sort keys are value expressions which would make
> both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't raise an
> error.
[the following paragraph is more a general philosophy than this specific
case]
Well we can choose to if we want to. Supporting only a subset of
expressions would still be in-line with the standard. Sometimes it is
better not to support something where specified behaviour is unclear
and/or of no benefit. Then you don't get tied into awkward backwards
compatibility issues when you discover the wrong choice of behaviour was
made.
In this specific case though it seems that special casing integer
literals is the way to go.
Dan.
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
On further investigation, it appears that the use of literal values as
sort keys is not valid SQL in the 1999 version (18.d on page 653).
However, in SQL-2003 that restriction has been removed, I would think
because ORDER BY can now be used in more places (e.g. arrays, analytics).
Further, on page 654 of SQL-1999 note 287 expressly says that the
facility from SQL-92 to use a signed integer as the sort specification
no longer exists (although I don't have that spec doc with me to confirm
the older syntax form).
Given that, I think the ability to use an integer literal is a useful
extension for compatibility with SQL-1992 but beyond that we should
treat everything as a value expression per the 1999 and 2003 specs.
--
Jeremy
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>
>>
> > If it made it clearer I would prefer that a compilation error is raised
>
>> for order by expressions that do resolve to constants, since supporting
>> them adds no value. How this error would be raised I'm not sure about.
>>
>> ORDER BY 1 - ok (column position 1)
>> ORDER BY C1 - ok
>> ORDER BY FN(C1) - ok
>> ORDER BY 1 + 1 - disallow
>> ORDER BY C1/C1 - disallow
>>
>
> The spec says that the sort keys are value expressions which would make
> both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't raise an
> error.
>
> In both cases the result is implementation dependent as the key will be
> the same for all rows. I think /choosing/ to define the result when the
> value expression is a simple integer literal is useful so we can support
> the "ORDER BY 1,2" syntax common on other platforms; I believe anything
> more complex than that is going to be confusing.
>
> This may make the parser more complex, but that's a development issue
> not a user one :-)
>
> --
> Jeremy
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Daniel John Debrunner wrote:
>
> If it made it clearer I would prefer that a compilation error is raised
> for order by expressions that do resolve to constants, since supporting
> them adds no value. How this error would be raised I'm not sure about.
>
> ORDER BY 1 - ok (column position 1)
> ORDER BY C1 - ok
> ORDER BY FN(C1) - ok
> ORDER BY 1 + 1 - disallow
> ORDER BY C1/C1 - disallow
>
The spec says that the sort keys are value expressions which would make
both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't raise an
error.
In both cases the result is implementation dependent as the key will be
the same for all rows. I think /choosing/ to define the result when the
value expression is a simple integer literal is useful so we can support
the "ORDER BY 1,2" syntax common on other platforms; I believe anything
more complex than that is going to be confusing.
This may make the parser more complex, but that's a development issue
not a user one :-)
--
Jeremy
Re: About improvement of DERBY-134
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Jack Klebanoff wrote:
> I think that most people would be surprised to find that "ORDER BY 1 +
> 1" behaves differently than "ORDER BY 2". I also think that it is
> simpler for us to treat all integer constants the same. It is hard to
> get the parser to distinguish between a literal constant and a complex
> expression that starts with an integer literal. That is why Tomohito
> Nakayama needed to use complex lookahead in his parser change.
>
> I think that it is better to distinguish between integer constants and
> other expressions in the OrderByColumn class. ValueNodes have
> isConstantExpression(), getTypeID(), and getConstantValueAsObject()
> methods that OrderByColumn can use to see if the expression is an
> integer constant and, if so, what the value is. OrderByColumn can test
> whether the order by expression is an instanceOf ColumnReference or
> ResultColumn to special case a simple column reference. This simplifies
> the parser significantly and causes us to treat "ORDER BY 1 + 1" the
> same as "ORDER BY 2".
Whichever path is taken, we need some very clearly defined rules, such
that we understand what the sort order will be with different
expressions. I'm nervous about sometimes expressions map to values and
sometimes to column positions.
If C1 is an integer column, then is
ORDER BY C1/C1 the same as ORDER BY 1
??
I can imagine a compiler in the future that looked for constant
expressions and replaced them with actual constants, that code should
not care about what is in the tree above it.
If it made it clearer I would prefer that a compilation error is raised
for order by expressions that do resolve to constants, since supporting
them adds no value. How this error would be raised I'm not sure about.
ORDER BY 1 - ok (column position 1)
ORDER BY C1 - ok
ORDER BY FN(C1) - ok
ORDER BY 1 + 1 - disallow
ORDER BY C1/C1 - disallow
Dan.
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
Jeremy Boynes wrote:
> Jack Klebanoff wrote:
>
>>
>> 1. sqlgrammar.jj. I think that creating a new method,
>> isNonReservedKeyword() to determine whether a token is a non-reserved
>> keyword or not, is a maintenance problem. Whenever we add a new
>> non-reserved keyword we must add it to the list of tokens, to
>> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
>> it in two places is difficult enough to discover or remember. If we need
>> isNonReservedKeyword then we should find a way of combining
>> nonReservedKeyword and isNonReservedKeyword so that only one of them
>> keeps the list of non-reserved key words.
>>
>> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
>> key type. A column name is just one kind of <expression>. If the parser
>> treats it as an expression we should still get the right ordering. I
>> think that it would better if the parser did so. The OrderByColumn class
>> can special case a simple column reference expression, as an
>> optimization. This considerably simplifies parsing sort keys.
>>
>> The only sort key type that has to be handled specially is that of an
>> integer constant. That specifies one of the select list columns as the
>> sort key. This case can be recognized in the parser, as is done in the
>> patch, or it can be recognized in OrderByColumn. In this alternative the
>> parser always creates OrderByColumn nodes with the sort key given by an
>> expression (a ValueNode). At bind time OrderByColumn can determine
>> whether the sort key expression is an integer constant, and if so treat
>> it as a column position.
>>
>> The two alternatives differ in the way that they treat constant integer
>> expressions like "ORDER BY 2-1". The patch orders the rows by the
>> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
>> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
>> an integer constant sort key expression as a result column position then
>> "ORDER BY 2-1" would cause the rows to be ordered on the first result
>> column, which I think is more usefull.
>>
>
> From the SQL spec, the <sort-key> is simply a value expression
> evaluated for each row. Hence "ORDER BY 2-1" means that all rows are
> peers and the ordering is implementation-dependent.
>
> I think allowing the value-expressions to evaluate to column position
> is potentially confusing. For example, suppose you have "ORDER BY ?" -
> do we order by the supplied value (which would be the same for all
> rows making the actual ordering implementation-dependent) or do we
> order by the column position (with the potential need to re-select
> indexes used to assist in ordering).
>
> I believe it is simple and SQL-compliant to have very simple rules here:
> 1) if all <sort-key>s are integer literals, then sort by the column
> position they imply. This is SQL-compliant as the comparison criteria
> for each row will be the same, making all rows peers and the actual
> order implementation dependent (we just define ours as using the
> appropriate column value).
>
> 2) if any <sort-key> is not an integer literal then we treat all of them
> as <value expression> and compare rows accordingly.
>
> --
> Jeremy
>
I think that most people would be surprised to find that "ORDER BY 1 +
1" behaves differently than "ORDER BY 2". I also think that it is
simpler for us to treat all integer constants the same. It is hard to
get the parser to distinguish between a literal constant and a complex
expression that starts with an integer literal. That is why Tomohito
Nakayama needed to use complex lookahead in his parser change.
I think that it is better to distinguish between integer constants and
other expressions in the OrderByColumn class. ValueNodes have
isConstantExpression(), getTypeID(), and getConstantValueAsObject()
methods that OrderByColumn can use to see if the expression is an
integer constant and, if so, what the value is. OrderByColumn can test
whether the order by expression is an instanceOf ColumnReference or
ResultColumn to special case a simple column reference. This simplifies
the parser significantly and causes us to treat "ORDER BY 1 + 1" the
same as "ORDER BY 2".
I don't feel strongly enough about this to block a patch that is well
tested and otherwise works correctly.
Jack Klebanoff
Re: About improvement of DERBY-134
Posted by Jeremy Boynes <jb...@apache.org>.
Jack Klebanoff wrote:
>
> 1. sqlgrammar.jj. I think that creating a new method,
> isNonReservedKeyword() to determine whether a token is a non-reserved
> keyword or not, is a maintenance problem. Whenever we add a new
> non-reserved keyword we must add it to the list of tokens, to
> nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
> it in two places is difficult enough to discover or remember. If we need
> isNonReservedKeyword then we should find a way of combining
> nonReservedKeyword and isNonReservedKeyword so that only one of them
> keeps the list of non-reserved key words.
>
> It is not necessary for the parser to recognize 3 cases of ORDER BY sort
> key type. A column name is just one kind of <expression>. If the parser
> treats it as an expression we should still get the right ordering. I
> think that it would better if the parser did so. The OrderByColumn class
> can special case a simple column reference expression, as an
> optimization. This considerably simplifies parsing sort keys.
>
> The only sort key type that has to be handled specially is that of an
> integer constant. That specifies one of the select list columns as the
> sort key. This case can be recognized in the parser, as is done in the
> patch, or it can be recognized in OrderByColumn. In this alternative the
> parser always creates OrderByColumn nodes with the sort key given by an
> expression (a ValueNode). At bind time OrderByColumn can determine
> whether the sort key expression is an integer constant, and if so treat
> it as a column position.
>
> The two alternatives differ in the way that they treat constant integer
> expressions like "ORDER BY 2-1". The patch orders the rows by the
> constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
> "ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
> an integer constant sort key expression as a result column position then
> "ORDER BY 2-1" would cause the rows to be ordered on the first result
> column, which I think is more usefull.
>
From the SQL spec, the <sort-key> is simply a value expression
evaluated for each row. Hence "ORDER BY 2-1" means that all rows are
peers and the ordering is implementation-dependent.
I think allowing the value-expressions to evaluate to column position is
potentially confusing. For example, suppose you have "ORDER BY ?" - do
we order by the supplied value (which would be the same for all rows
making the actual ordering implementation-dependent) or do we order by
the column position (with the potential need to re-select indexes used
to assist in ordering).
I believe it is simple and SQL-compliant to have very simple rules here:
1) if all <sort-key>s are integer literals, then sort by the column
position they imply. This is SQL-compliant as the comparison criteria
for each row will be the same, making all rows peers and the actual
order implementation dependent (we just define ours as using the
appropriate column value).
2) if any <sort-key> is not an integer literal then we treat all of them
as <value expression> and compare rows accordingly.
--
Jeremy
Re: About improvement of DERBY-134
Posted by Jack Klebanoff <kl...@sbcglobal.net>.
TomohitoNakayama wrote:
> Hello.
>
> I have put some LOOKAHEAD to sqlgrammer.jj and
> add some test pattern to orderby.sql.
>
> Would someone review patch please ?
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "TomohitoNakayama"
> <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Sunday, February 13, 2005 4:09 PM
> Subject: Re: About improvement of DERBY-134
>
>
>> Sorry.
>> Mistaken.
>>
>> LOOKAHEAD()....
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Sunday, February 13, 2005 3:42 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>> Hello.
>>>
>>> Thank's for your reviewing.
>>> Grammer ambiguity is very critical problem ....
>>>
>>> I will try to put LOOKUP() and consider about testing..
>>>
>>> #World is not simple as I wish to be.....
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: Satheesh Bandaram
>>> To: Derby Development
>>> Sent: Saturday, February 12, 2005 4:10 AM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>> I think the patch is a good start. But more work needs to be done.
>>> Based on a quick review, some of the items to be completed are:
>>> (there may be more)
>>>
>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
>>> is written. Since orderby expression and orderby column can both
>>> start with an identifier, this causes ambiguity. Need to rewrite or
>>> add lookup to avoid this.
>>> Current patch doesn't seem to support all expressions, Ex: select i
>>> from t1 order by i/2. So, needs more work.
>>> Add more test cases and test outputs to show changed behavior. You
>>> could add test cases to orderby.sql test that is already part of
>>> functionTests/tests/lang.
>>> I do encourage you to continue work on this ...
>>>
>>> Satheesh
>>>
>>> TomohitoNakayama wrote:
>>>
>>> I tried to solve DERBY-134.
>>> Patch is attached to this mail.
>>>
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: "Derby Development" <de...@db.apache.org>
>>> Sent: Wednesday, February 09, 2005 5:33 PM
>>> Subject: Re: About improvement of DERBY-134
>>>
>>>
>>>
>>> Woops.
>>> Mistaken.
>>>
>>>
>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>> sensitive way"
>>>
>>>
>>>
>>> That's "DERBY-134 Sorted string columns are sorted in a case
>>> sensitive way"
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> ----- Original Message ----- From: "TomohitoNakayama"
>>> <to...@basil.ocn.ne.jp>
>>> To: <de...@db.apache.org>
>>> Sent: Wednesday, February 09, 2005 4:35 PM
>>> Subject: About improvement of DERBY-134
>>>
>>>
>>>
>>> Hello.
>>> My name is Naka.
>>> I'm very newbie in derby community.
>>>
>>> I'm now seeing report for derby in ASF Jira.
>>> And found a interesting issue.
>>>
>>> That's "DERBY-124 Sorted string columns are sorted in a case
>>> sensitive way"
>>>
>>> This issue seems to mean that we can't use complex item in order
>>> clause.
>>> #That title was difficult to understand a bit ....
>>>
>>> Solving this isn't useful?
>>> Especially when we manipulate DBMS by hand.
>>>
>>> What I think we need to do is as next:
>>>
>>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2)
>>> Make OrderByColumn class to support additiveExpression.
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> tomoihto@rose.zero.ad.jp
>>> tomonaka@basil.ocn.ne.jp
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>>
I have worked on Derby/Cloudscape for a few years and have even fixed
one or two ORDER BY bugs in the past. I have reviewed your patch. It is
close, but I have some problems with it.
1. sqlgrammar.jj. I think that creating a new method,
isNonReservedKeyword() to determine whether a token is a non-reserved
keyword or not, is a maintenance problem. Whenever we add a new
non-reserved keyword we must add it to the list of tokens, to
nonReservedKeyword(), and now to isNonReservedKeyword(). Having to add
it in two places is difficult enough to discover or remember. If we need
isNonReservedKeyword then we should find a way of combining
nonReservedKeyword and isNonReservedKeyword so that only one of them
keeps the list of non-reserved key words.
It is not necessary for the parser to recognize 3 cases of ORDER BY sort
key type. A column name is just one kind of <expression>. If the parser
treats it as an expression we should still get the right ordering. I
think that it would better if the parser did so. The OrderByColumn class
can special case a simple column reference expression, as an
optimization. This considerably simplifies parsing sort keys.
The only sort key type that has to be handled specially is that of an
integer constant. That specifies one of the select list columns as the
sort key. This case can be recognized in the parser, as is done in the
patch, or it can be recognized in OrderByColumn. In this alternative the
parser always creates OrderByColumn nodes with the sort key given by an
expression (a ValueNode). At bind time OrderByColumn can determine
whether the sort key expression is an integer constant, and if so treat
it as a column position.
The two alternatives differ in the way that they treat constant integer
expressions like "ORDER BY 2-1". The patch orders the rows by the
constant 1, which is not usefull. With the patch "ORDER BY 2-1 ASC" and
"ORDER BY 2-1 DESC" produce the same ordering. If OrderByColumn treated
an integer constant sort key expression as a result column position then
"ORDER BY 2-1" would cause the rows to be ordered on the first result
column, which I think is more usefull.
2. OrderByColumn. I think that there is a mistake in the patch to the
bindOrderByColumn method of class OrderByColumn.
The new code is
}else if(expression != null){
ResultColumn col = null;
int i = 0;
for(i = 0;
i < targetCols.size();
i ++){
col = targetCols.getOrderByColumn(i);
if(col != null &&
col.getExpression() == expression){
break;
}
}
Method ResultColumnList.getOrderByColumn( int) uses 1 indexing. The
patch assumes 0 indexing. So the loop really should be "for( i = 1; i <=
targetCols.size(); i++)".
(Java likes 0 indexing while SQL likes 1 indexing. So some parts of the
Derby code use 0 indexing while others use 1 indexing. The resulting
confusion has caught most of us at one time or another).
The result is that when the sort key is an expression
OrderByColumn.pullUpOrderByColumn adds it to the end of the target list,
but OrderByColumn.bindOrderByColumn doesn't find it.
OrderByColumn.bindOrderByColumn tests whether the second last column in
the target list is orderable. This is usually not right. Consider the
following SQL:
create table tblob( id int, b blob(1000));
select id,b from tblob order by abs(id);
select b,id from tblob order by abs(id);
The first SELECT raises the error "ERROR X0X67: Columns of type 'BLOB'
may not be used in CREATE INDEX, ORDER BY, GROUP BY, UNION, INTERSECT,
EXCEPT or DISTINCT, because comparisons are not supported for that
type". The second SELECT executes properly.
3. Testing. I would like to see some additional tests: the failing case
above; ORDER BY expressions combined with ASC and DESC, to ensure that
the compiler handles ASC and DESC after a sort key, and comma separated
lists of ORDER BY expressions.
Jack
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
I have put some LOOKAHEAD to sqlgrammer.jj and
add some test pattern to orderby.sql.
Would someone review patch please ?
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Sunday, February 13, 2005 4:09 PM
Subject: Re: About improvement of DERBY-134
> Sorry.
> Mistaken.
>
> LOOKAHEAD()....
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Sunday, February 13, 2005 3:42 PM
> Subject: Re: About improvement of DERBY-134
>
>
>> Hello.
>>
>> Thank's for your reviewing.
>> Grammer ambiguity is very critical problem ....
>>
>> I will try to put LOOKUP() and consider about testing..
>>
>> #World is not simple as I wish to be.....
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message -----
>> From: Satheesh Bandaram
>> To: Derby Development
>> Sent: Saturday, February 12, 2005 4:10 AM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>> I think the patch is a good start. But more work needs to be done. Based
>> on a quick review, some of the items to be completed are: (there may be
>> more)
>>
>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch is
>> written. Since orderby expression and orderby column can both start with
>> an identifier, this causes ambiguity. Need to rewrite or add lookup to
>> avoid this.
>> Current patch doesn't seem to support all expressions, Ex: select i from
>> t1 order by i/2. So, needs more work.
>> Add more test cases and test outputs to show changed behavior. You could
>> add test cases to orderby.sql test that is already part of
>> functionTests/tests/lang.
>> I do encourage you to continue work on this ...
>>
>> Satheesh
>>
>> TomohitoNakayama wrote:
>>
>> I tried to solve DERBY-134.
>> Patch is attached to this mail.
>>
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: "Derby Development" <de...@db.apache.org>
>> Sent: Wednesday, February 09, 2005 5:33 PM
>> Subject: Re: About improvement of DERBY-134
>>
>>
>>
>> Woops.
>> Mistaken.
>>
>>
>> That's "DERBY-124 Sorted string columns are sorted in a case sensitive
>> way"
>>
>>
>>
>> That's "DERBY-134 Sorted string columns are sorted in a case sensitive
>> way"
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>> ----- Original Message ----- From: "TomohitoNakayama"
>> <to...@basil.ocn.ne.jp>
>> To: <de...@db.apache.org>
>> Sent: Wednesday, February 09, 2005 4:35 PM
>> Subject: About improvement of DERBY-134
>>
>>
>>
>> Hello.
>> My name is Naka.
>> I'm very newbie in derby community.
>>
>> I'm now seeing report for derby in ASF Jira.
>> And found a interesting issue.
>>
>> That's "DERBY-124 Sorted string columns are sorted in a case sensitive
>> way"
>>
>> This issue seems to mean that we can't use complex item in order clause.
>> #That title was difficult to understand a bit ....
>>
>> Solving this isn't useful?
>> Especially when we manipulate DBMS by hand.
>>
>> What I think we need to do is as next:
>>
>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2) Make
>> OrderByColumn class to support additiveExpression.
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>>
>>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Sorry.
Mistaken.
LOOKAHEAD()....
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Sunday, February 13, 2005 3:42 PM
Subject: Re: About improvement of DERBY-134
> Hello.
>
> Thank's for your reviewing.
> Grammer ambiguity is very critical problem ....
>
> I will try to put LOOKUP() and consider about testing..
>
> #World is not simple as I wish to be.....
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: Satheesh Bandaram
> To: Derby Development
> Sent: Saturday, February 12, 2005 4:10 AM
> Subject: Re: About improvement of DERBY-134
>
>
> I think the patch is a good start. But more work needs to be done. Based
> on a quick review, some of the items to be completed are: (there may be
> more)
>
> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch is
> written. Since orderby expression and orderby column can both start with
> an identifier, this causes ambiguity. Need to rewrite or add lookup to
> avoid this.
> Current patch doesn't seem to support all expressions, Ex: select i from
> t1 order by i/2. So, needs more work.
> Add more test cases and test outputs to show changed behavior. You could
> add test cases to orderby.sql test that is already part of
> functionTests/tests/lang.
> I do encourage you to continue work on this ...
>
> Satheesh
>
> TomohitoNakayama wrote:
>
> I tried to solve DERBY-134.
> Patch is attached to this mail.
>
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "TomohitoNakayama"
> <to...@basil.ocn.ne.jp>
> To: "Derby Development" <de...@db.apache.org>
> Sent: Wednesday, February 09, 2005 5:33 PM
> Subject: Re: About improvement of DERBY-134
>
>
>
> Woops.
> Mistaken.
>
>
> That's "DERBY-124 Sorted string columns are sorted in a case sensitive
> way"
>
>
>
> That's "DERBY-134 Sorted string columns are sorted in a case sensitive
> way"
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message ----- From: "TomohitoNakayama"
> <to...@basil.ocn.ne.jp>
> To: <de...@db.apache.org>
> Sent: Wednesday, February 09, 2005 4:35 PM
> Subject: About improvement of DERBY-134
>
>
>
> Hello.
> My name is Naka.
> I'm very newbie in derby community.
>
> I'm now seeing report for derby in ASF Jira.
> And found a interesting issue.
>
> That's "DERBY-124 Sorted string columns are sorted in a case sensitive
> way"
>
> This issue seems to mean that we can't use complex item in order clause.
> #That title was difficult to understand a bit ....
>
> Solving this isn't useful?
> Especially when we manipulate DBMS by hand.
>
> What I think we need to do is as next:
>
> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2) Make
> OrderByColumn class to support additiveExpression.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Hello.
Thank's for your reviewing.
Grammer ambiguity is very critical problem ....
I will try to put LOOKUP() and consider about testing..
#World is not simple as I wish to be.....
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: Satheesh Bandaram
To: Derby Development
Sent: Saturday, February 12, 2005 4:10 AM
Subject: Re: About improvement of DERBY-134
I think the patch is a good start. But more work needs to be done. Based on
a quick review, some of the items to be completed are: (there may be more)
Grammar ambiguity. SortKey() has grammar ambiguity the way the patch is
written. Since orderby expression and orderby column can both start with an
identifier, this causes ambiguity. Need to rewrite or add lookup to avoid
this.
Current patch doesn't seem to support all expressions, Ex: select i from t1
order by i/2. So, needs more work.
Add more test cases and test outputs to show changed behavior. You could add
test cases to orderby.sql test that is already part of
functionTests/tests/lang.
I do encourage you to continue work on this ...
Satheesh
TomohitoNakayama wrote:
I tried to solve DERBY-134.
Patch is attached to this mail.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "TomohitoNakayama"
<to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, February 09, 2005 5:33 PM
Subject: Re: About improvement of DERBY-134
Woops.
Mistaken.
That's "DERBY-124 Sorted string columns are sorted in a case sensitive way"
That's "DERBY-134 Sorted string columns are sorted in a case sensitive way"
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message ----- From: "TomohitoNakayama"
<to...@basil.ocn.ne.jp>
To: <de...@db.apache.org>
Sent: Wednesday, February 09, 2005 4:35 PM
Subject: About improvement of DERBY-134
Hello.
My name is Naka.
I'm very newbie in derby community.
I'm now seeing report for derby in ASF Jira.
And found a interesting issue.
That's "DERBY-124 Sorted string columns are sorted in a case sensitive way"
This issue seems to mean that we can't use complex item in order clause.
#That title was difficult to understand a bit ....
Solving this isn't useful?
Especially when we manipulate DBMS by hand.
What I think we need to do is as next:
1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj". 2) Make
OrderByColumn class to support additiveExpression.
Best regards.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 2005/02/10
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
I tried to solve DERBY-134.
Patch is attached to this mail.
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: "Derby Development" <de...@db.apache.org>
Sent: Wednesday, February 09, 2005 5:33 PM
Subject: Re: About improvement of DERBY-134
> Woops.
> Mistaken.
>
>> That's
>> "DERBY-124 Sorted string columns are sorted in a case sensitive way"
>
>
> That's
> "DERBY-134 Sorted string columns are sorted in a case sensitive way"
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> ----- Original Message -----
> From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
> To: <de...@db.apache.org>
> Sent: Wednesday, February 09, 2005 4:35 PM
> Subject: About improvement of DERBY-134
>
>
>> Hello.
>> My name is Naka.
>> I'm very newbie in derby community.
>>
>> I'm now seeing report for derby in ASF Jira.
>> And found a interesting issue.
>>
>> That's
>> "DERBY-124 Sorted string columns are sorted in a case sensitive way"
>>
>> This issue seems to mean that we can't use complex item in order clause.
>> #That title was difficult to understand a bit ....
>>
>> Solving this isn't useful?
>> Especially when we manipulate DBMS by hand.
>>
>> What I think we need to do is as next:
>>
>> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj".
>> 2) Make OrderByColumn class to support additiveExpression.
>>
>> Best regards.
>>
>> /*
>>
>> Tomohito Nakayama
>> tomoihto@rose.zero.ad.jp
>> tomonaka@basil.ocn.ne.jp
>>
>> Naka
>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>
>> */
>>
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>>
>>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
Re: About improvement of DERBY-134
Posted by TomohitoNakayama <to...@basil.ocn.ne.jp>.
Woops.
Mistaken.
> That's
> "DERBY-124 Sorted string columns are sorted in a case sensitive way"
That's
"DERBY-134 Sorted string columns are sorted in a case sensitive way"
/*
Tomohito Nakayama
tomoihto@rose.zero.ad.jp
tomonaka@basil.ocn.ne.jp
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "TomohitoNakayama" <to...@basil.ocn.ne.jp>
To: <de...@db.apache.org>
Sent: Wednesday, February 09, 2005 4:35 PM
Subject: About improvement of DERBY-134
> Hello.
> My name is Naka.
> I'm very newbie in derby community.
>
> I'm now seeing report for derby in ASF Jira.
> And found a interesting issue.
>
> That's
> "DERBY-124 Sorted string columns are sorted in a case sensitive way"
>
> This issue seems to mean that we can't use complex item in order clause.
> #That title was difficult to understand a bit ....
>
> Solving this isn't useful?
> Especially when we manipulate DBMS by hand.
>
> What I think we need to do is as next:
>
> 1) Allow additiveExpression() in sortKey() in "sqlgrammer.jj".
> 2) Make OrderByColumn class to support additiveExpression.
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> tomoihto@rose.zero.ad.jp
> tomonaka@basil.ocn.ne.jp
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 2005/02/07