[jira] Created: (DERBY-3276) Order by on aggregate always does a sort even if the sort is not needed.

[Manish Khettry (JIRA)]

Order by on aggregate always does a sort even if the sort is not needed.


 Key: DERBY-3276
 URL: https://issues.apache.org/jira/browse/DERBY-3276
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Manish Khettry


See DERBY-3231 for details.

A few different variations of queries that do not need a sort are:

select b, max(a) from yy where a=5 group by b order by max(a) asc;
select b, max(a) from yy where a=5 group by b order by max(a) desc;

Also consider

select a, sum(b) from yy group by a having sum(b) = 2 order by sum(b);





-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

DERBY-3236. 

Mike, I'll take a look at DERBY-3257. 

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: d3231_v2.patch, order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

mkhettry edited comment on DERBY-3231 at 12/14/07 11:18 AM:
--

DERBY-3276 

Mike, I'll take a look at DERBY-3257. 

  was (Author: mkhettry):
DERBY-3236. 

Mike, I'll take a look at DERBY-3257. 
  
 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: d3231_v2.patch, order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

Well, I thought it was better to fix the wrong results and look at 
optimizations later on as a separate bug. I pointed out another kind of query 
in an earlier comment where we could do this sort avoidance thing.

A slightly more abstract question-- how important is it for Derby to do 
optimizations like this? The downsides are code complexity and unanticipated 
bugs like this one while the benefits are restricted to queries, which as you 
put it, you can't imagine too many people writing? 

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

I did not look into the phantom column behavior; just getting rid of the 
faulty logic which assumed the sort column was a constant expression did the 
trick. 

+1 on your proposal.




 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

I ran the junit lang suite.

1. Prior to 681, the query would get rewritten with a subselect so the 
aggregate node in the order by would be transformed to a column reference.
2. The optimization is only done if whereClause != null (SelectNode around line 
910 or so)



 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-3231:
--

Attachment: order_by_bug.diff.txt

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-3231:
--

Derby Info: [Patch Available, Existing Application Impact, Regression]  
(was: [Regression, Existing Application Impact])

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

The problem was missing methods isConstant and isConstantExpression for 
AggregateNodes. The super class implementation would return true causing Derby 
to eliminate the order by.

isConstantExpression is used to eliminate sorts in queries like this:

select c1, c2
from t
where c1=2
order by c1;

In this case, we have an aggregate as the sort column and this sort of 
optimization will apply to queries like this:

select c1, count(*)
from t
group by c1
having count(*) = 2
order by count(*);

To remove constant sort columns the code in SelectNode#preProcess (around line 
915) will have to be modified to consider having clauses as well.  

For now, I return false for both methods-- it is more important to get correct 
results for this query first.


 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical
 Attachments: order_by_bug.diff.txt


 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2457) Use of column aliases in group by / having clauses can cause queries to fail

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-2457:
-

Assignee: (was: Manish Khettry)

Don't have the time to look into this right now.


 Use of column aliases in group by / having clauses can cause queries to fail
 

 Key: DERBY-2457
 URL: https://issues.apache.org/jira/browse/DERBY-2457
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.3.1.4
Reporter: Andrew McIntyre
Priority: Minor
 Attachments: 1624_repro.sql


 Some use of column aliases in group by / having clauses can cause queries to 
 fail with error 42X04. The queries can sometimes be made to work by also 
 aliasing the table or rewriting the query to use a subselect. Attached is a 
 simple sql script which reproduces the issue, originally found as part of 
 DERBY-1624.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-3231:
-

Assignee: Manish Khettry

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical

 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

Interestingly if you leave out the where clause, the query works just fine.

ij select b, count(*) from yy  group by b order by count(*) asc;
B |2
--
4.0   |1
7.0   |2
3.0   |4



 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical

 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

mkhettry edited comment on DERBY-3231 at 12/4/07 10:58 PM:
-

A.B, did this query work before svn revision 516454 and fail after this commit?

  was (Author: mkhettry):
A.B, did this query work before svn revision 516454? 
  
 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical

 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3231) Sorting on COUNT with OR and GROUP BY delivers wrong results.

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3231:
---

A.B, did this query work before svn revision 516454? 

 Sorting on COUNT with OR and GROUP BY delivers wrong results.
 -

 Key: DERBY-3231
 URL: https://issues.apache.org/jira/browse/DERBY-3231
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4
 Environment: Eclipse 3.2.2; java 1.5.0_11; 
Reporter: Peter Balon
Assignee: Manish Khettry
Priority: Critical

 The result of the select is not sorted in order by COUNT(*) DESC or order 
 by COUNT(*) ASC 
 create table yy (a double, b double);
 insert into yy values (2, 4);
 insert into yy values (5, 7);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (2, 3);
 insert into yy values (9, 7);
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) asc
 -- same result as:
 select b, COUNT(*) AS COUNT_OF, SUM(b) AS sum b 
 from yy
 where a = 5 or a = 2
 group by b
 order by COUNT(*) desc

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3050) Convert groupBy.sql tests to JUnit and include them in GroupByTest.java

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3050:
---

A few thoughts on the test case.

1. The testcase creates and drops the fixtures (tables t1,t2) that it needs If 
the test fails, the tables will not be dropped causing potential problems if 
others add more tests to this suite. It may be better to move the table 
creation to a setUp method or better still to a oneTimeSetup or atleast 
dropping the tables in a finally block.

2. Do you think its worth the effort to break up the new test case testGroupBy 
into smaller test cases? There are several advantages to small test cases-- for 
one, if you encounter a failure, it does not hide other problems down the test 
case. Second it can quickly clue you to the nature of the failure. The comments 
in the test provide a handy way to split up the test case; i.e. 

// ?s in group by
// group by on long varchar type
// having clause cannot contain column references which 
// are not grouping columns

If a test case called testParamInGroupBy fails, the person investigating the 
failure has a *lot* more to go by then a failure in testGroupBy.



 Convert groupBy.sql tests to JUnit and include them in GroupByTest.java
 ---

 Key: DERBY-3050
 URL: https://issues.apache.org/jira/browse/DERBY-3050
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Affects Versions: 10.4.0.0
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor
 Attachments: convertToJUnit.diff, convertToJUnit.stat


 There are currently 3 sets of GROUP BY tests:
  - GroupByExpressionTest.java
  - GroupByTest.java
  - groupBy.sql
 The first two tests are JUnit tests; the groupBy.sql tests are old-style 
 harness tests,
 although they are now run in the JUnit framework using the LangScripts 
 technique.
 This sub-task proposes to convert the groupBy.sql tests to JUnit tests, and 
 to include
 them directly into GroupByTest.java.
 The DERBY-2151 conversion tool can be used to assist in the conversion 
 process.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2911:
---

One thought on the ConcurrentCache class. Since this is a Java 5 class,  is it 
possbie to use generics? In this case something like:

ConcurrentCacheK {
  private final ConcurrentHashMapK, CacheEntry cache;
}

I realize that most of (or all) the time, users of this class will be pre jdk 5 
classes and this may not buy us all that much but it is still worth doing I 
think. 

 Implement a buffer manager using java.util.concurrent classes
 -

 Key: DERBY-2911
 URL: https://issues.apache.org/jira/browse/DERBY-2911
 Project: Derby
  Issue Type: Improvement
  Components: Performance, Services
Affects Versions: 10.4.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
 Attachments: d2911-1.diff, d2911-1.stat, d2911-2.diff, 
 d2911-unused.diff, d2911-unused.stat, d2911perf.java


 There are indications that the buffer manager is a bottleneck for some types 
 of multi-user load. For instance, Anders Morken wrote this in a comment on 
 DERBY-1704: With a separate table and index for each thread (to remove latch 
 contention and lock waits from the equation) we (...) found that 
 org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 
 times more contention than the synchronization in LockSet.lockObject() and 
 LockSet.unlock(). That might be an indicator of where to apply the next push.
 It would be interesting to see the scalability and performance of a buffer 
 manager which exploits the concurrency utilities added in Java SE 5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3024) Validation of shared plans hurts scalability

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3024:
---

That is very interesting. A couple of thoughts on this.

First, the point of sharing plans is to avoid doing potentially expensive 
compilation. By choosing a really simple query which is cheap both to compile 
and execute you are effectively measuring only the cost of sharing plans. If 
you had even a slightly more expensive query, I doubt you would see such a huge 
disparity between the two cases. 

That having been said, the lack of any speedup is troubling. I ran the same 
query to see how many times the routines you mentioned 
(GenericPreparedStatement#upToDate and BaseActivation#checkStatementValdity) 
are executed. The first one is called *five* times per query and the second one 
*once*. I haven't looked at the code too closely but it does seem excessive and 
could be a starting point to investigate contention.
 
Also, there are two other routines GPS#finish and GPS#getActivation which 
synchronize on the GPS and are called once per statement so these routines add 
to the contention as well.



 Validation of shared plans hurts scalability
 

 Key: DERBY-3024
 URL: https://issues.apache.org/jira/browse/DERBY-3024
 Project: Derby
  Issue Type: Improvement
  Components: Performance, SQL
Affects Versions: 10.4.0.0
 Environment: Sun Java SE 6, Solaris 10, Sun Fire V880 (8 CPUs)
Reporter: Knut Anders Hatlen
Priority: Minor
 Attachments: Values.java, values1.png


 To investigate whether there was anything in the SQL execution layer that 
 prevented scaling on a multi-CPU machine, I wrote a multi-threaded test which 
 continuously executed VALUES 1 using a PreparedStatement. I ran the test on 
 a machine with 8 CPUs and expected the throughput to be proportional to the 
 number of concurrent clients up to 8 clients (the same as the number of 
 CPUs). However, the throughput only had a small increase from 1 to 2 clients, 
 and adding more clients did not increase the throughput. Looking at the test 
 in a profiler, it seems like the threads are spending a lot of time waiting 
 to enter synchronization blocks in GenericPreparedStatement.upToDate() and 
 BaseActivation.checkStatementValidity() (both of which are synchronized on 
 the a GenericPreparedStatement object).
 I then changed the test slightly, appending a comment with a unique thread id 
 to the VALUES 1 statement. That means the threads still did the same work, 
 but each thread got its own plan (GenericPreparedStatement object) since the 
 statement cache didn't regard the SQL text strings as identical. When I made 
 that change, the test scaled more or less perfectly up to 8 concurrent 
 threads.
 We should try to find a way to make the scalability the same regardless of 
 whether or not the threads share the same plan.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3002) Add support for GROUP BY ROLLUP

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-3002:
---

If I read the diff correctly, you're sorting the same data multiple times? Is 
it not possible to compute the rollups with a single sort? The wiki page also 
suggests that this is possible. 




 Add support for GROUP BY ROLLUP
 ---

 Key: DERBY-3002
 URL: https://issues.apache.org/jira/browse/DERBY-3002
 Project: Derby
  Issue Type: Sub-task
  Components: SQL
Affects Versions: 10.4.0.0
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor
 Attachments: prototypeChangeNoTests.diff


 Provide an implementation of the ROLLUP form of multi-dimensional grouping 
 according to the SQL standard.
 See http://wiki.apache.org/db-derby/OLAPRollupLists for some more detailed 
 information about this aspect of the SQL standard.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: DERBY-581 and OLAP operations

[Manish Khettry]

Bryan,

It sounds like a very reasonable and thoughtful way to get started. One
thing which is frustrating about working with Derby is that large portions
of the code are so very cryptic and brittle, sometimes unnceccsarily so.
Having more than one person try and understand relevant code, documenting it
and sharing this information would help in more ways than one.

The other thing-- is it possible to get a hold of the relevant portions of
the SQL standard that you refer to?

m



On 7/18/07, Bryan Pendleton [EMAIL PROTECTED] wrote:


In the context of https://issues.apache.org/jira/browse/DERBY-581
I've been studying the SQL-99 standard's specification of
OLAP operations:
  - Feature T611 specifies Elementary OLAP operations
  - Feature T612 specifies Advanced OLAP operations

I'm interested in exploring an implementation of these features,
and to start with I'd like to get the community's reaction:
  - Are these features that we're interested in seeing added to Derby?
  - Are there others in the community who are interested in
working on these features?
  - How could we approach this incrementally, building enough
functionality to be useful, arriving at a complete
implementation in pieces over time? For example, would it be
reasonable to build a subset of the T611 features at first,
and then expand that functionality over time? Would it be
reasonable to add new SQL syntax support, but have it work
only in a subset of cases, and then expand the execution
functionality over time to address more usages?

I was thinking that I might get started by trying to build
one or more Wiki pages that describe some of the materials
that might go into an implementation:
  - background information about the features and the
concepts behind them
  - notes about the current Derby implementation, and about
possible ways to extend the implementation in this area
  - ideas for how to subdivide and stage the implementation,
in order to enable us to start talking about actual code.

Does this seem like a reasonable approach?

thanks,

bryan

[jira] Updated: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2689:
--

Attachment: (was: deadlock3.patch.txt)

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, deadlock2.patch.txt, 
 TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2689:
--

Attachment: deadlock3.patch.txt

another one with license granted. I've already signed an ICLA-- do I still need 
to do this on a per-attachment basis?!


 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, deadlock2.patch.txt, 
 deadlock3.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2689:
--

Attachment: deadlock3.patch.txt

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, deadlock2.patch.txt, 
 deadlock3.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2689:
---

fyi-- I attached another patch.



 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, deadlock2.patch.txt, 
 deadlock3.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2689:
---

Thanks for looking at the patch. 

As far as 2 goes-- if we set unusedActs to false at the beginning of the loop 
and while trying to close all activations, get an exception won't we end up 
with the case where unusedActs = false, yet there are unused activations which 
the loop did not get to?

For 1, there seems to be no synchronization at all in this class. It is my 
understanding that a LangugageConnectionContext is scoped within a connection 
and only one thread may be using a lcc at a given time. Is that correct? The 
only case seems to be the finalize method of ResultSet which can end up marking 
unsedActs.

On the same note, I'm not sure I understand why we have to do the following:

for (int i = acts.size() - 1; i = 0; i--) {

// it maybe the case that a reset() ends up closing
// one or more activation leaving our index beyond
// the end of the array
if (i = acts.size())
continue;

Can the acts arraylist  bemodified by multiple threads? Also why don't all 
other routines employ this extra check? Look for example at 
lookupCursorActivation, checkIfAnyActivationHasHoldCursor, 
verifyAllHeldResultSetsAreClosed among others.

Also, yes there seem to be some wierd characters which have crept up in the 
comments. I'll take them out of the next patch.



 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source

[jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2689:
---

re: walking the acts list, Dan in DERBY-418, suggested that we recheck if the 
index is within bounds. 
http://issues.apache.org/jira/browse/DERBY-418#action_12430512. I can't seem to 
see why this would be necessary-- Dan, am I missing something? If this is the 
case, then all the routines that walk acts can be cleaned up, I think.

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2689:
--

Attachment: deadlock.patch.txt

I have moved the logic that closes unused activations. Earlier this was done 
when a activation was initialized and added to a lcc.

at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
 Source)
at org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
Source)
at 
org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown 
Source)
at 
org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
 Source)
at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown Source) 

Now it is done by the caller (outside a synchronized block) whenever a 
statement is prepared or executed in GenericPreparedStatement:getActivation.

For testing, I ran the reproduction attached with this bug. Without the bugfix 
it would deadlock within a few minutes. I let it run all morning and all the 
threads were making progress before I stopped the threads around noon. I also 
ran the reproduction with DERBY-418. Without the cleanup code being invoked, 
the test would run out of memory after about 230K iterations (with 20m heap 
size). With the bugfix I let it run to about 1m iterations before stopping the 
process. Also derbylang.

The patch was made against trunk. 

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source

[jira] Updated: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2689:
--

Derby Info: [Patch Available]

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2794) Document ansi trim functionality

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2794:
--

Attachment: trim_doc

A first cut at the ansi trim functionality.

 Document ansi trim functionality
 

 Key: DERBY-2794
 URL: https://issues.apache.org/jira/browse/DERBY-2794
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Manish Khettry
Assignee: Manish Khettry
 Attachments: trim_doc


 Several examples can be found in the junit test (AnsiTrimTest). The unit test 
 is in java/testing/org/apache/derbyTesting/functionTests/tests/lang.
 There is also the documentation from the ANSI spec which Dag had posted in a 
 comment in DERBY-1623.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2794) Document ansi trim functionality

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2794:
--

Derby Info: [Patch Available]

 Document ansi trim functionality
 

 Key: DERBY-2794
 URL: https://issues.apache.org/jira/browse/DERBY-2794
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Manish Khettry
Assignee: Manish Khettry
 Attachments: trim_doc


 Several examples can be found in the junit test (AnsiTrimTest). The unit test 
 is in java/testing/org/apache/derbyTesting/functionTests/tests/lang.
 There is also the documentation from the ANSI spec which Dag had posted in a 
 comment in DERBY-1623.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2689:
---

Thought I'd update the bug with what I'm trying right now--I think option 2 
outlined in Brian's earlier comment is the cleanest in this case. I have moved 
the cleanup activation code to the constructor for EmbedConnection after the 
call to getActivation around line ~140 or so.

try {
preparedStatement = lcc.prepareInternalStatement
(lcc.getDefaultSchema(), sql, 
resultSetConcurrency==JDBC20Translation.CONCUR_READ_ONLY, forMetaData);


addWarning(preparedStatement.getCompileTimeWarnings());

activation = preparedStatement.getActivation(lcc, 
resultSetType == JDBC20Translation.TYPE_SCROLL_INSENSITIVE);

// DERBY-2689. Close unused activations here 
when I'm not inside a monitor.
lcc.closeUnusedActivations();

I've been running the test case for both this bug and DERBY-418 to make sure 
that we have no deadlocks and no memory leaks.


 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Sorry, I guess not all issues were addressed.

re: space vs tabs-- the new file AnsiTrimTest is all spaces I think. Please do 
not put any tabs in there!
6-- trim in SQLChar/StringDataValue is not being generated by the code 
generator anymore. However I do not know if there are existing triggers or 
query plans on disk which refer to it so I did not remove it. If upgrade is not 
an issue then by all means the trim function should go away or ansiTrim should 
just be named trim.
8. I hadn't thought of documentation but I could take a stab at it or atleast 
open a subtask for it.
If it does make it to 10.3, then it should be buddy tested.



 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 1623_take2.patch.txt, AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DERBY-2794) Document ansi trim functionality

[Manish Khettry (JIRA)]

Document ansi trim functionality


 Key: DERBY-2794
 URL: https://issues.apache.org/jira/browse/DERBY-2794
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Manish Khettry


Several examples can be found in the junit test (AnsiTrimTest). The unit test 
is in java/testing/org/apache/derbyTesting/functionTests/tests/lang.

There is also the documentation from the ANSI spec which Dag had posted in a 
comment in DERBY-1623.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-2689:
-

Assignee: Manish Khettry

 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2689) Deadlock with GenericPreparedStatement

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2689:
---

Since nobody has claimed this as yet and its critical, I can take a look. 
Hopefully I'll have an update early next week. 


 Deadlock with GenericPreparedStatement
 --

 Key: DERBY-2689
 URL: https://issues.apache.org/jira/browse/DERBY-2689
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.2.2.0
 Environment: Windows
Reporter: Marc Ewert
Assignee: Manish Khettry
Priority: Critical
 Attachments: TestDerbyPreparedStatements.java


 We encountered two times a deadlock inside of derby. It seems that we can't 
 workaround it. The involved two threads are attached, it looks like a 
 classical deadlock:
 Thread-22 daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry 
 [0x1317f000..0x1317fd4c]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x047beb00 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]
 ThreadPoolThread-SyncScheduler-3-1 prio=2 tid=0x0e620400 nid=0xfec waiting 
 for monitor entry [0x10a7e000..0x10a7fa14]
java.lang.Thread.State: BLOCKED (on object monitor)
   at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown 
 Source)
   - waiting to lock 0x05306f88 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
  Source)
   at 
 org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown 
 Source)
   at 
 org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
  Source)
   at 
 org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
  Source)
   at org.apache.derby.impl.sql.GenericActivationHolder.init(Unknown 
 Source)
   at 
 org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown 
 Source)
   - locked 0x052f4d70 (a 
 org.apache.derby.impl.sql.GenericPreparedStatement)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.init(Unknown 
 Source)
   at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown 
 Source)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
   - locked 0x04225178 (a org.apache.derby.impl.jdbc.EmbedConnection40)
   at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown 
 Source)
 [custom methods]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2794) Document ansi trim functionality

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-2794:
-

Assignee: Manish Khettry

 Document ansi trim functionality
 

 Key: DERBY-2794
 URL: https://issues.apache.org/jira/browse/DERBY-2794
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Reporter: Manish Khettry
Assignee: Manish Khettry

 Several examples can be found in the junit test (AnsiTrimTest). The unit test 
 is in java/testing/org/apache/derbyTesting/functionTests/tests/lang.
 There is also the documentation from the ANSI spec which Dag had posted in a 
 comment in DERBY-1623.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-1623:
--

Attachment: 1623_take2.patch.txt

Followup patch. Addresses all the issues raised by A. B. Ran derbylang and all 
lang junit tests.


 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 1623_take2.patch.txt, AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Thanks for reviewing the code. All your points are valid and 1 is a pretty 
egregious mistake on my part. As far as 4 goes-- yes, it does have to be in 
reservedKeyword but is there a problem if its in miscBuiltinsCore? I needed to 
add the token there because the ansi trim is parsed inside the 
characterValueFunction production which in turn is under the miscBuiltinsCore 
production. Infact this comment in miscBuiltinsCore says:

 miscBuiltinsCore() are the core
 * system, string and numeric functions.
 * NOTE: date functions not currently considered
 * core for purposes of the grammar since
 * they can only be escaped when they appear
 * as functions (not special registers).

So is trim not a core function?



 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-1623:
--

Attachment: 1623.patch.txt

 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-1623:
--

Derby Info: [Patch Available]

I apologize for not being able to wrap this up sooner-- work has taken up more 
than 40 hours of time these last few weeks.

trim,leading,trailing,both are now reserved keywords. 

 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

The bugfix is in the attachment, 1623.patch.txt



 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
Assignee: Manish Khettry
 Attachments: 1623-parser-guess.diff, 1623.patch.txt, 
 AnsiTrimTest.java, compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: 10.3 release coming up...fast!

[Manish Khettry]

I have been working on DERBY-1623 but have had little time to finish it up. 
I'll try to submit a patch before 6/1 but its unlikely.

m
- Original Message 
From: Kristian Waagan [EMAIL PROTECTED]
To: derby-dev@db.apache.org
Sent: Wednesday, May 30, 2007 3:52:34 AM
Subject: Re: 10.3 release coming up...fast!

Myrna van Lunteren wrote:
 Hi!
 
 We have now about 7 days before the code complete date of 6/1/07!
 

[ snip ]

 1. code complete 6/1
 
 For those of you who plan to have functionality fixed/completed in
 10.3, please analyze your progress, and let me know if you think you
 will not make that date.

Hello Myrna,

I'm working to get DERBY-2646 (Cleanup of Clob control/support 
structures) done for 10.3.

It will be kind of tight, but I think I will make it. Also, the issue is 
kind of blocking other issues/jiras, so it is on top of my list.



regards,
-- 
Kristian

[ snip ]








   
Choose
 the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Thanks Andrew-- if you have those queries saved up, it would be a good starting 
point for writing tests. BTW, I did try this query and it came back with a NPE 
which is a good thing ;)

ij select v from t where TRIM(v) = TRIM(c)
;
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.


 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry
 Attachments: 1623-parser-guess.diff, AnsiTrimTest.java, 
 compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-1623:
--

Attachment: sqlgrammar.jj.diff

I think this grammar would work. What do you think Andrew?

 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry
 Attachments: 1623-parser-guess.diff, AnsiTrimTest.java, 
 compile_error.jj, sqlgrammar.jj.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Andrew,

I am going by snippets of the spec posted in this bug. I did take character 
value expression to mean any expression that yields a char/varchar/clob value. 
I also tried a few queries in mysql which did accept case and other 
expressions. Does DB2 accept them as well?

 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry
 Attachments: 1623-parser-guess.diff, AnsiTrimTest.java


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Andrew

Thanks for taking the time to take a look at this. I took your grammar and 
wrote some unit tests for it (only the parsing part). I've attached the Test. 
As you can see, the characterValueExpression production does not cover all the 
cases which can apply to trimCharacter or trimSource.

Second, I was trying to make the tokens LEADING/TRAILING/BOTH as non reserved 
keyword. I'm not sure if that is going possible. For example in a query like:

select LEADING from col. 

is LEADING a trimspec or is it a column name? The problem with making these 
reserved keywords is that it may break existing code.

I will spend more time when its available to working on this-- if anyone else 
has thoughts on how to come up with an unambiguous grammar, please do jump in.


 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry
 Attachments: 1623-parser-guess.diff


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-1623:
--

Attachment: AnsiTrimTest.java

Unit test for parsing trim expressions.


 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry
 Attachments: 1623-parser-guess.diff, AnsiTrimTest.java


 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

I have spent several days but I cannot seem to express the grammar for trim 
without warnings from JavaCC. The warning says: 

 [java] Warning: Choice conflict involving two expansions at
 [java]  line 6268, column 5 and line 6279, column 5 respectively.
 [java]  A common prefix is: leading +
 [java]  Consider using a lookahead of 3 or more for earlier 
expansion

I've included a skeleton of the production rules that I'm using.  I'm also not 
sure if additiveExpression is the right production to use in this case.

ValueNode
ansiTrimProduction() throws StandardException :
{
}
{
LEADING additiveExpression(null, 0, false)
{
return null;//TODO obviously return a ValueNode when warnings are 
fixed.
}
|
LOOKAHEAD ( LEADING FROM)
LEADING FROM additiveExpression(null,0,false)
{
return null;
}
|
LEADING additiveExpression(null,0,false) FROM 
additiveExpression(null,0,false)
{
return null;
}
}

From reading the JavaCC documentation and this tutorial 
(https://javacc.dev.java.net/doc/lookahead.html) it seems the parser does not 
which production (the first or the third) to take when it reads a token like 
(+). Using a fixed lookahead to disambiguate between the two productions is 
not possible in this case. For now, I'm sort of stuck at this point. Any 
ponters would be appreciated.


 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry

 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Yes, I agree the better thing to do is to implement the sql standard and leave 
ltrim/rtrimalone. 

I don't have ready access to the sql standard so I'm a litlle unsure about the 
trim character. I'm taking it as a string literal. Looking at this page, 
http://www.oreilly.com/catalog/sqlnut/chapter/ch04.html, it looks like, it is 
interpreted as a string that needs to be removed. i.e.

trim(leading 'ab' from 'bac') = bac
trim(leading 'ba' from 'bac') = c

and not as I'd thought earlier a set of characters to be removed.



 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry

 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry resolved DERBY-681.
--

Resolution: Fixed

This commit by Army, http://svn.apache.org/viewvc?view=revrev=518687, resolves 
issue. 

 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, 
 followup.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

I'm thinking of adding an optional argument to the existing LTRIM and RTRIM 
functions. This will be a string literal and is basically the set of chars to 
trim.

RTRIM('abcxyzxx', 'zyx') = abc.

Also a new function TRIM with the same arguments as L/R TRIM which trims both 
leading and trailing characters. If anyone has any thoughts let me know.





 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry

 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1623) Add ANSI TRIM implementation

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-1623:
---

Its pretty much in the description of this bug. I found this as well  
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt.



 Add ANSI TRIM implementation
 

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry

 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry closed DERBY-2442.
-


 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt, 
 post681.refactor2.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2457) Use of column aliases in group by / having clauses can cause queries to fail

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-2457:
-

Assignee: Manish Khettry

 Use of column aliases in group by / having clauses can cause queries to fail
 

 Key: DERBY-2457
 URL: https://issues.apache.org/jira/browse/DERBY-2457
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Andrew McIntyre
 Assigned To: Manish Khettry
Priority: Minor
 Attachments: 1624_repro.sql


 Some use of column aliases in group by / having clauses can cause queries to 
 fail with error 42X04. The queries can sometimes be made to work by also 
 aliasing the table or rewriting the query to use a subselect. Attached is a 
 simple sql script which reproduces the issue, originally found as part of 
 DERBY-1624.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-1623) Consider ANSI TRIM implementation

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-1623:
-

Assignee: Manish Khettry

 Consider ANSI TRIM implementation
 -

 Key: DERBY-1623
 URL: https://issues.apache.org/jira/browse/DERBY-1623
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Emmanuel Bernard
 Assigned To: Manish Khettry

 JPA is requiring databases to support this ANSI feature esp the ability to 
 chose the trimmed character
 TRIM([ [ LEADING | TRAILING | BOTH ] [ chars ] FROM ] str)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Attachment: post681.refactor2.txt

ValueNod#clause RIP.  

I ran derbylang, junit-all.


 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt, 
 post681.refactor2.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2442:
---

This is the last patch for this bug. 


 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt, 
 post681.refactor2.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Derby Info: [Patch Available]

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt, 
 post681.refactor2.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reopened DERBY-2442:
---


Sorry, to reopen this but there is atleast another set of changes that are 
coming up. Thanks for the quick review and commit.



 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Attachment: post681.refactor1.txt

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2442:
---

the second patch, performs cleanup on FromSubquery and FromList-- removed 
instance variables generatedForGroupByClause and generatedForHavingClause. They 
can be applied together or separately. Ran junit-all and derbylang.


 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt, post681.refactor1.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2463) Create runtime statistics parser for junit tests

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2463:
---

These questions may be silly but here goes

1. Is it possible that the RuntimeStatisticsParser constructor can be called 
with a null value for rts?
2. Since the procedure SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS() returns a 
RuntimeStatistics object it seems a shame to convert this object to a string 
and then parse it. Is it possible to manipulate this object directly?
3. A common usage for something like this would be
  a. set runtime statistics on
  b. parse and possibly execute query. 
  c. look at runtime stats.
It would be nice if there was a helper method to combine all these steps into 
one routine especially if the test does not care about results returned in 2.
4. It would be nice if we could extract other information from this parser, not 
just the isolation level!



 Create runtime statistics parser for junit tests
 

 Key: DERBY-2463
 URL: https://issues.apache.org/jira/browse/DERBY-2463
 Project: Derby
  Issue Type: Sub-task
  Components: Test
Reporter: Kathey Marsden
 Assigned To: Kathey Marsden
Priority: Minor
 Attachments: DERBY-2463.diff


 Tests need to extract information such as isolation level from runtime 
 statistics.  Add a utility class to do this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2442:
---

I'm sorry-- I had two different sets of changes in my environment. If you 
update to svn # 518687, this patch should compile. 

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Derby Info: [Patch Available]

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry updated DERBY-681:
-

Attachment: followup.patch.txt

query with a having clause but without a group by has a generated aggregaegt 
added on. I made visibleSize() less restrictive-- i.e. it takes into accounts 
all generated columns not just those added in GroupByList#bindGroupByColumns.

Another follow up item for me to look at is the different mechanism used for 
order by columns which are added to the select list. This is completely 
different from how group by does things.

I ran junit-all and derbylang. 

 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, 
 followup.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Attachment: post681.refactor.txt

In SelectNode, the instance variables generatedForGoupByClause and 
generatedForHavingClause are never set. I have removed these variables as well 
as code that depends on them being true. 

This is a small and self-contained patch. Hopefully someone can review this 
sooner than later. After this, the instance variables 
generatedForGroupByClause/HavingClause in FromSubquery.

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry updated DERBY-2442:
--

Derby Info: [Patch Available]

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: post681.refactor.txt


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-681:
--

OK. Do you think it makes sense to mark this bug as resolved and another to 
track this issue. Either way is fine.



 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (DERBY-47) Some possible improvements to IN optimization

[Manish Khettry]

 4) The code which traverses predicate lists seems to always traverse
them
in backwards order, e.g. this code from HashJoinStrategy.java:

 for (int i = storeRestrictionList.size() - 1; i = 0; i--)

Why do we always traverse these backwards? Is this just an
optimization
in order to call the size() method only once? Or is there something
deeper going on?

This is just habit more than anything.  A lot of the optimizer-related
work that I've been doing requires the removal of certain predicates from
predicate lists at various points in the code, and in that case reverse
traversal is better (because removal of elements from the rear does not
require adjustments to the loop index).  So I often write loop iteration
with backwards traversal out of sheer habit, even when removal of predicates
is not happening.  If you think this makes the code more confusing or less
intuitive I have no problems with switching to forward traversal.



A small suggestion on this backwards traversal-- if you use the Iterator
class, you can achieve the same thing in a much more readable way. The
change can be as simple as making the Vector in QueryTreeNodeVector a List
and adding an iterator method in QTNV class.

[jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-681:
--

hmmm, thanks for catching all of these. I should have thought about them and 
yes, it lis the correct fix.





 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2416) Provide a shell for a subclass of SQLChar which will use the passed Collator to do the collation rather than SQLChar's default collation of UCS_BASIC

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2416:
---

A couple of thoughts.

1. The name can simply be SQLCharWithCollation?

2. The cut and paste and one minor change in getIntArray is a bad idea. It 
should be possible to add a RuleBasedCollator parameter to getIntArray and 
reuse the code in the superclass?

i.e. in SQLChar

protected int[] getIntArray(RuleBasedCollator rbc) {
if (rbc == null) {
rbc = getLocaleFinder().getCollator();
}
// rest of the code.
}

in the subclass call getIntArray with rbc?


 Provide a shell for a subclass of SQLChar which will use the passed Collator 
 to do the collation rather than SQLChar's default collation of UCS_BASIC
 -

 Key: DERBY-2416
 URL: https://issues.apache.org/jira/browse/DERBY-2416
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Mamta A. Satoor
 Assigned To: Mamta A. Satoor
 Attachments: 
 DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v1.txt, 
 DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt


 This jira entry is one of the tasks involved in implementing DERBY-2336.
 The existing SQLChar datatype has the Derby's default collation which is 
 UCS_BASIC defined on them. With Derby 10.3, we want to support an additional 
 collation for char datatypes which will be based on the territory. This jira 
 issue is the placeholder for creating subclass of SQLChar which will use the 
 passed Collator to do the collation. The current use of this class in Derby 
 10.3 will be for territory based collation but this class can be used in 
 future for other kinds of collations like case-insensitive etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2416) Provide a shell for a subclass of SQLChar which will use the passed Collator to do the collation rather than SQLChar's default collation of UCS_BASIC

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-2416:
---

I am not sure what you mean by penalize SQLChar? If you mean runtime 
performance, my suggestion adds one conditional. Is that unacceptable 
performance penalty?



 Provide a shell for a subclass of SQLChar which will use the passed Collator 
 to do the collation rather than SQLChar's default collation of UCS_BASIC
 -

 Key: DERBY-2416
 URL: https://issues.apache.org/jira/browse/DERBY-2416
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Mamta A. Satoor
 Assigned To: Mamta A. Satoor
 Attachments: 
 DERBY2416_NewCharClassWithDifferentCollationSupport_diff_v1.txt, 
 DERBY2416_NewCharClassWithDifferentCollationSupport_stat_v1.txt


 This jira entry is one of the tasks involved in implementing DERBY-2336.
 The existing SQLChar datatype has the Derby's default collation which is 
 UCS_BASIC defined on them. With Derby 10.3, we want to support an additional 
 collation for char datatypes which will be based on the territory. This jira 
 issue is the placeholder for creating subclass of SQLChar which will use the 
 passed Collator to do the collation. The current use of this class in Derby 
 10.3 will be for territory based collation but this class can be used in 
 future for other kinds of collations like case-insensitive etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2442) Remove code made redundant by DERBY-681

[Manish Khettry (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manish Khettry reassigned DERBY-2442:
-

Assignee: Manish Khettry

 Remove code made redundant by DERBY-681
 ---

 Key: DERBY-2442
 URL: https://issues.apache.org/jira/browse/DERBY-2442
 Project: Derby
  Issue Type: Task
  Components: SQL
Affects Versions: 10.3.0.0
Reporter: Manish Khettry
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0


 The instance variables, generatedForGroupByClause and 
 generatedForHavingClause are not set anymore. Investigate code that 
 references these variables to see if it still makes sense in the new 
 dispensation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Google Summer of Code

[Manish Khettry]

Could people who were mentors last year share their experience? Did any code 
from the mentees make it to the codeline?

 I apologize if this information exists in a public place but a quick look at 
the derby wiki was negative.


David Van Couvering [EMAIL PROTECTED] wrote: This is happening, and timing is 
tight.  Ross Gardler 
([EMAIL PROTECTED]) would like to know if you're interested in being a 
mentor.  This is not a commitment to actually mentor, nor is it a 
guarantee that you'll have a mentee.

Ross says:

So, please express your interest in being a mentor by adding yourself 
tothe wiki page at http://wiki.apache.org/general/SummerOfCode2007
*AND* by letting me know your GMail account details via a reply to this
mail (probably best to make that offlist to keep the noise down).

David


 
-
Now that's room service! Choose from over 150,000 hotels 
in 45,000 destinations on Yahoo! Travel to find your fit.

Refactoring derby code

[Manish Khettry]

while working on DERBY-681, I came across much code that could benefit from 
refactoring. Most of these were small almost trivial but in the end I think it 
makes the code more tractable and easy to work with and I did not add it to the 
patch because it makes the patch more difficult to review.

I was thinking of filing a JIRA issue and adding patches to it which hopefully 
someone can review and commit or is there a better way to do it?

m

 
-
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry updated DERBY-681:
-

Attachment: 681.patch3.txt

removed runtest, runsuite. fixed views.


 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry updated DERBY-681:
-

Attachment: 681.patch2.txt

Again, thanks for very detailed and constructive review and for finding the 
problems with union/views/create table. I ran derbylang (one failure 
compressTable once, DERBY-2117?) and junit-all (one failure in a derbynet 
tearDown method?). Normally I would try to track this failure but this bugfix 
has been sitting on my laptop for too long and it really doesn't look like 
anything to do with my changes (famous last words?!)

I have accepted most of the review comments from A. B atleast partially except 
for 4, 6 and 9.


 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, 681.patch2.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-681:
--

Just a quick note to address two issues raised by Army.

DERBY-1624: It won't fix all the queries attached by Andrew for this bug 
because we don't resolve aliases in the group by/having/orderby clauses; the 
following query will fail. This bug does not address aliases-- only the 
original query with this bug.

select x as alias, sum(y)
from t 
group by alias;

The size vs visible size is more problematic-- I really think the language 
layer should not be using RCL directly as much as it currently does. If it 
wants to check the number of columns returned by a ResultSetNode, it should 
call a method in the RSN called either visibleSize or runtimeSize  or some such 
(i.e. the # of columns actually returned by the result set node). The only way 
to find all of these would be to grind through all the occurences of RCL.size! 
This in itself should suggest that the use of these classes/methods in this 
little area itself (i.e. # of columns in a result set node) could deal with a 
good dose of refactoring. 

Thanks for looking at the patch, running tests and asking the right questions. 
I appreciate the time you've taken for this patch. I am a little busy at work 
but will get back to this bug when things let up (hopefully next week). 


 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: https://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

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

Manish Khettry commented on DERBY-681:
--

Thanks for reviewing the patch. It will take me sometime to make the patch 
current and look at your comments. It has, after all, been a while since I 
submitted the patch.

I am curious-- is it typical for a patch to gather dust for a few months before 
someone finds the time to look at it? And if so, is this a good thing?

Thanks,
Manish

A B (JIRA) [EMAIL PROTECTED] wrote: 
[ 
https://issues.apache.org/jira/browse/DERBY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471852
 ] 

A B commented on DERBY-681:
---

I noticed that this issue is now on the bottom of the patch available 
list--and that the patch was posted almost two months ago.  So I did a quick 
review and my comments are below.  Note: The patch is out of date (not 
surprisingly); it would be great if a newer version could be re-attached that 
incorporates the following comments (I am willing to continue the 
review/discussion until the patch is committed).



I think the difference between a fetch size of 1 and a fetch size of 16 comes 
down to the difference between a TableScan and BulkTableScan.  I did a quick 
search of the codeline and it looks like Derby will disable bulk fetching if 
the result set is ordering dependent (see SelectNode.genProjectRestrict()) 
and also for certain min/max optimizations in a group by (see the 
considerPostOptimizeOptimization() method of GroupByNode).  My guess is that 
your changes have somehow made it so that we no longer need to disable bulk 
fetch for certain queries, and thus you are now seeing a different fetch size.  
This seems particular likely since all of the queries that show a 1 vs 16 
difference in aggregateOptimization() come under the heading of group by 
ordered on grouping columns.  So long story short, my feeling is that this is 
an acceptable diff...

Hopefully someone will correct me if I'm wrong...

Also (w.r.t to notes.txt as attached to this issue):

  -- The notes you wrote for Background on Group By would be great as
  javadoc comments in the GroupByNode.addNewColumnsForAggregation() method
  (in addition to what's already there).

  -- The notes you wrote for Having clause - Design would be great as
  comments in the GroupByNode.addAggregateColumns() method (perhaps just
  before the if (havingClause != null)...)

Other review comments (note: I haven't done much actual testing yet, I've just 
looked at the code changes; I hope to do more testing of the changes next 
week...):

I think it would good if the following issues could be addressed before commit:

  1) FromBaseTable.java:

  -- It looks like you added an accept() method to FromBaseTable that
  overrides ResultSetNode.accept().  I noticed that ResultSetNode.accept()
  recursively calls accept on resultColumns, but the new method in
  FromBaseTable does not.  This means that in cases where we used to accept
  visitors for base table result columns we will no longer do so.  I don't
  know what the effects of that might be, but I think that's probably not
  good.  It would perhaps be better to call super.accept() at the start
  of FromBaseTable.accept() and then go from there.

  2) GroupByNode.java:

  -- init() method has some lines that are commented out.  You mention
  these in your notes.txt file but there is no explanation as to why
  they are commented out (and not just deleted) in the file itself;
  might be good to add such comments (you could just take them from
  notes.txt).

  3) ResultColumnList.java:

  -- With the following diff:

-int size = (size()  sourceRCL.size()) ? size() : sourceRCL.size();
+//  int size = (size()  sourceRCL.size()) ? size() : sourceRCL.size();
+int size = Math.min(size(), sourceRCL.size());

  The original line (which is now commented out) looks like it assigns size
  to be the *max* of size() and sourceRCL.size(); but your changes make it
  use the minimum.  I looked at the code and I think your fix is correct--
  i.e. that we should be using the minimum size.  So should the other line
  just be deleted (instead of commented out)?  Also, there appears to be an
  implicit assumption that if the lists are two different sizes then the
  shorter one must correspond to the _leading_ columns of the longer one.
  If you're so inclined it might be nice to add a comment saying as much
  (to go along with your change here).

  4) ColumnReference.java:

  -- Unrelated (and perhaps accidental) code cleanup diff; better to leave
  this out of the patch.

  5) GroupByExpressionTest.java:

  -- In the testSubSelect() method of you added a test case that is
  identical to the one immediately preceding it (so far as I can tell).
  Was that intentional, or is there a HAVING clause missing

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-681?page=all ]

Manish Khettry updated DERBY-681:
-

Attachment: 681.patch.txt

This patch removes the wrap group by's in a subselect rewrite in the parser. 
It preserves the having clause through bind and optimize phases and during the 
final rewrite for aggregates in the GroupByNode, transforms the having clause 
to a valid restriction. I am also attaching a text file which should clarify 
the changes.

This patch also fixes related bugs DERBY-1624, the regresssion introduced by 
DERBY-280 and also completes the functionality for DERBY-883. 

If this patch is approved and comitted I will file another bug to remove 
references to the flags generatedForGroupBy and geneatedForHaving which is dead 
code post this patch. I did not remove these references because it would make 
the patch even bigger and more complicated.



 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: http://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-681?page=all ]

Manish Khettry updated DERBY-681:
-

Attachment: notes.txt

Notes on this patch.


 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: http://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-681?page=all ]

Manish Khettry updated DERBY-681:
-

Derby Info: [Patch Available]

 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: http://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry
 Attachments: 681.patch.txt, notes.txt


 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-64) Create a table with a query

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-64?page=comments#action_12457097 ] 

Manish Khettry commented on DERBY-64:
-

I spent some time looking at the patch and it looks like a good first stab at 
the compile and bind phase. The execution of this DDL takes place in in 
CreateTableConstantAction. I would think that to populate the table with the 
results of the queryr, you would need to call generate on the query tree and 
somehow execute it. It may also help to see how a simple select query is 
compiled to byte code and executed.

I should add the caveat that I am not a commiter and not very familiar with the 
code since I work on it off and on, so hopefully others more familiar with the 
code  will jump in with their take on the patch.

Do existing tests psas with your changes? It seems even without the WITH DATA 
option it is a useful addition to the sysetm.



 Create a table with a query
 ---

 Key: DERBY-64
 URL: http://issues.apache.org/jira/browse/DERBY-64
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Reporter: Christian d'Heureuse
 Assigned To: James F. Adams
 Attachments: Derby64Patch1.txt, Derby64Patch2.txt


 I suggest to implement a SQL statement to create and fill a table with a 
 query, without having to write the columns definition.
 e.g.:
  CREATE TABLE new_table AS SELECT ...;
 or:
  SELECT ... INTO new_table FROM ...;

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Use of synchronized containers in engine code

[Manish Khettry]

The language code uses Vector and Hashtable as well. I'm not very sure what
objects in the language layer are shared between across objects but I would
think that the bulk of stuff under impl/sql/compile could use unsync
collections?


On 12/4/06, Knut Anders Hatlen [EMAIL PROTECTED] wrote:


Hi,

I think I once read that the engine code in some cases uses
synchronized containers because the code was written before the
unsynchronized containers were added to the JDK, and not because
synchronization was needed. Is that correct?

I traced some simple operations and found that methods in synchronized
Hashtables and Vectors were called from these classes:

  * SinglePool/LockSet (lock manager)
  * Clock (cache manager)
  * java.util.Observable
  * org.apache.derby.impl.store.access.RAMTransaction
  * org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext

The lock manager and the cache manager are accessed by multiple
concurrent threads, so they obviously need some kind of
synchronization. java.util.Observable is part of the JDK, so its
internal implementation is not under Derby's control. However, I'm not
sure that the synchronization is needed in RAMTransaction and
GenericLanguageConnectionContext.

In RAMTransaction, there is no explicit synchronization, but it
contains four Vectors and one Hashtable. Is it safe to assume that
RAMTransaction's methods are called from a single thread only and that
Vector/Hashtable could be replaced with ArrayList/HashMap?

In GenericLanguageConnectionContext, there are two for-loops which
iterate over the activations Vector and have this comment:

/* For every activation */
// synchronize on acts as other threads may be closing activations
// in this list, thus invalidating the Enumeration

However, I don't see how the code that follows this comment is safe if
another thread is modifying the Vector concurrently. For instance,
there is nothing that prevents another thread from removing an element
from the vector between the index calculation and the actual access to
the vector. This made me wonder whether the synchronization was needed
in the first place. Isn't it so that a thread will attempt to
synchronize on the connection object before it accesses the language
connection context? Or are there other ways to access the lcc?

I don't know these classes well enough to say whether it is safe to
replace the synchronized containers with unsynchronized ones, but I
hope someone more familiar with the code will comment.

Thanks,

--
Knut Anders

[jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-681?page=comments#action_12455195 ] 

Manish Khettry commented on DERBY-681:
--

Thanks Andrew. I hope that I can eliminate the group/having query rewrite and 
this should fix DERBY-1624. 

On the blog entry-- I do think that being able to use aliases in the query 
(group by or where clause) would be helpful. I remember seeing a bug about this 
issue a while ago. 

 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: http://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry

 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-2016) ArrayIndexOutOfBoundsException for COALESCE with aggregate functions

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-2016?page=comments#action_12452589 ] 

Manish Khettry commented on DERBY-2016:
---

The visit method is used to traverse the parse tree and in this case, replace 
aggregates with ColumnReferences. See ReplaceAggregatesWIthCRVisitior. 
CoalesceFunctionNode does seem to have a visit method but there is also a 
cached ValueNode in this class (firstNonParameterNode) which is not visited 
which causes this assert failure.


 ArrayIndexOutOfBoundsException for COALESCE with aggregate functions
 

 Key: DERBY-2016
 URL: http://issues.apache.org/jira/browse/DERBY-2016
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.2.1.6
 Environment: 1.5.0_06-b05
Reporter: Christian d'Heureuse
 Assigned To: Julius Stroffek

 The following statements produce an ArrayIndexOutOfBoundsException:
 CREATE TABLE t1 (
f1 INTEGER);
 SELECT COALESCE(MAX(f1),0) FROM t1;
 Workaround:
VALUES COALESCE( (SELECT MAX(f1) FROM t1), 0);
 Stack trace:
 
 2006-10-29 14:52:53.765 GMT:
  Booting Derby version The Apache Software Foundation - Apache Derby - 
 10.2.1.6 - (452058): instance c013800d-010e-948f-0faa-0012f418
 on database directory C:\temp_sys\temp_Derby_TestErr_db
 Database Class Loader started - derby.database.classpath=''
 2006-10-29 14:53:02.906 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), 
 (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Cleanup 
 action starting
 2006-10-29 14:53:02.906 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), 
 (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Failed 
 Statement is: SELECT COALESCE(MAX(f1),0) FROM t1
 java.lang.ArrayIndexOutOfBoundsException: -1
 at org.apache.derby.impl.services.bytecode.BCMethod.popStack(Unknown 
 Source)
 at 
 org.apache.derby.impl.services.bytecode.BCMethod.callMethod(Unknown Source)
 at 
 org.apache.derby.impl.sql.compile.ResultColumnList.generateCore(Unknown 
 Source)
 at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(Unknown 
 Source)
 at 
 org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(Unknown Source)
 at 
 org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(Unknown
  Source)
 at org.apache.derby.impl.sql.compile.CursorNode.generate(Unknown 
 Source)
 at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown 
 Source)
 at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown 
 Source)
 at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
 at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
  Source)
 at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
 at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
 at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
 at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
 at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.go(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source)
 at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source)
 at org.apache.derby.tools.ij.main(Unknown Source)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-681?page=all ]

Manish Khettry reassigned DERBY-681:


Assignee: Manish Khettry

 Eliminate the parser's rewriting of the abstract syntax tree for queries with 
 GROUP BY and/or HAVING clauses
 

 Key: DERBY-681
 URL: http://issues.apache.org/jira/browse/DERBY-681
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Reporter: Rick Hillegas
 Assigned To: Manish Khettry

 If a query contains a GROUP BY or HAVING clause, the parser rewrites the 
 abstract syntax tree, putting aggregates into a subselect and treating the 
 HAVING clause as the WHERE clause of a fabricated outer select from the 
 subquery. This allows the compiler to re-use some machinery since the HAVING 
 clause operates on the grouped result the way that the WHERE clause operates 
 on the from list. Unfortunately, this rewriting creates an explosion of 
 special cases in the compiler after parsing is done. The rewriting is not 
 systematically handled later on in the compiler. This gives rise to defects 
 like bug 280. We need to eliminate this special rewriting and handle the 
 HAVING clause in a straightforward way. This is not a small bugfix but is a 
 medium sized project.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Functions in GROUP BY expressions? (related to DERBY-883)

[Manish Khettry]

Actually, when I was implementing this functionality I thought that
comparing java nodes for equivalence was not possible or perhaps hard
to do. I could be wrong on this, so someone who knows this stuff better
can comment on this. At any rate, I find it strange that one of these query works but not the other. I think right now as things stand, both should fail. If there is consensus that we should allow java value nodes in group by expressions, then we should add isEquivalence methods to all the JavaValueNodes.
m
On 11/15/06, Oystein Grovlen - Sun Norway [EMAIL PROTECTED] wrote:
Manish Khettry wrote:  Hmm strange. I am not sure why this  select avg(i) from t group by sin(i)   works but not this,   select avg(i), sin(i) from test group by sin(i);
   I think its a bug-- both should be disallowed.Why should they be disallowed?I agree that in most cases grouping bynon-deterministic functions do not make sense, but I am not sure thatis a reason for disallowing it.Also, a function that is generally
non-deterministic may be deterministic in a given context.Theoretically, I do not see why equivalence and non-deterministicfunctions are an issue for GROUP BY.I do not think an implementationneed to execute the function twice if it appears both in the group-by
clause and in the select list.The value returned when determininggroup could be used for the select list also.--Øystein

Re: Functions in GROUP BY expressions? (related to DERBY-883)

[Manish Khettry]

Hmm strange. I am not sure why this  select avg(i) from t group by sin(i)works but not this, select avg(i), sin(i) from test group by sin(i);I think its a bug-- both should be disallowed.
mOn 11/14/06, Oystein Grovlen - Sun Norway [EMAIL PROTECTED] wrote:
Yip Ng wrote: For SIN, COS, TAN functions,they are also considered deterministics. However, they do not work currently in Derby with group by _expression_ as they are mapped toJavaToSQLValueNode and such nodes always return
 false in isEquivalent() method, so I think this is an implementation restriction for those built-in functions.Just some late follow-up here.As far as I can tell, it is not strictlycorrect to say that non-deterministic functions does not work with group
by expressions.What does not work is to use a non-deterministicfunction in the select list of a statement when grouping on the samefunction.However, the following query works:select avg(i) from t group by sin(i)
I assume that it is the check for equivalence between the select listand the group by list that requires deterministic functions.(This mayhave been clear to others when this was discussed, but at least not to me.)
--Øystein

[jira] Commented: (DERBY-2014) NullPointerException with NULLIF in GROUP BY clause

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-2014?page=comments#action_12445682 ] 

Manish Khettry commented on DERBY-2014:
---

The change to ConstantNode is fine. Thanks for finding and fixing this. On 
adding tests for this bug: Would it be better to add it to the JUnit test 
(GroupByExpression.java) rather than the old canon style test?

 NullPointerException with NULLIF in GROUP BY clause
 ---

 Key: DERBY-2014
 URL: http://issues.apache.org/jira/browse/DERBY-2014
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.2.1.6, 10.3.0.0
 Environment: Any
Reporter: Yip Ng
 Assigned To: Yip Ng
 Attachments: derby2014-trunk-diff01.txt, derby2014-trunk-stat01.txt


 A NPE occurs when NULLIF is used in the GROUP BY clause.
 ij create table t1 (c1 int);
 0 rows inserted/updated/deleted
 ij insert into t1 values 1,2,2,3;
 4 rows inserted/updated/deleted
 ij select nullif(c1,c1) from t1 group by nullif(c1,c1);
 ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
 Stacktrace:
 java.lang.NullPointerException
   at 
 org.apache.derby.impl.sql.compile.ConstantNode.isEquivalent(ConstantNode.java:285)
   at 
 org.apache.derby.impl.sql.compile.CastNode.isEquivalent(CastNode.java:1044)
   at 
 org.apache.derby.impl.sql.compile.ConditionalNode.isEquivalent(ConditionalNode.java:518)
   at 
 org.apache.derby.impl.sql.compile.GroupByList.findGroupingColumn(GroupByList.java:244)
   at 
 org.apache.derby.impl.sql.compile.VerifyAggregateExpressionsVisitor.skipChildren(VerifyAggregateExpressionsVisitor.java:146)
   at 
 org.apache.derby.impl.sql.compile.ConditionalNode.accept(ConditionalNode.java:484)
   at 
 org.apache.derby.impl.sql.compile.ResultColumn.accept(ResultColumn.java:1515)
   at 
 org.apache.derby.impl.sql.compile.QueryTreeNodeVector.accept(QueryTreeNodeVector.java:159)
   at 
 org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:619)
   at 
 org.apache.derby.impl.sql.compile.FromSubquery.bindExpressions(FromSubquery.java:262)
   at 
 org.apache.derby.impl.sql.compile.FromList.bindExpressions(FromList.java:337)
   at 
 org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:500)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:249)
   at 
 org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:162)
   at 
 org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java:253)
   at 
 org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:345)
   at 
 org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:119)
   at 
 org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:745)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:568)
   at 
 org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:517)
   at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:321)
   at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:517)
   at 
 org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:370)
   at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:268)
   at org.apache.derby.impl.tools.ij.Main.go(Main.java:204)
   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:170)
   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56)
   at org.apache.derby.tools.ij.main(ij.java:71)
 sysinfo:
 -- Java Information --
 Java Version:1.4.2_12
 Java Vendor: Sun Microsystems Inc.
 Java home:   C:\jdk142\jre
 Java classpath:  classes;.
 OS name: Windows XP
 OS architecture: x86
 OS version:  5.1
 Java user name:  yip
 Java user home:  C:\Documents and Settings\Administrator
 Java user dir:   C:\derby\trunk
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.4
 - Derby Information 
 JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
 [C:\derby\trunk\classes] 10.3.0.0 alpha - (1)
 --
 - Locale Information -
 Current Locale :  [English/United States [en_US]]
 Found support for locale: [de_DE]
  version: 10.3.0.0 alpha - (1)
 Found support for locale: [es]
  version: 10.3.0.0 alpha - (1)
 Found support for locale: [fr]
  version: 10.3.0.0 alpha - (1)
 Found support for locale: [it]
  version: 10.3.0.0 alpha - (1)
 Found support for locale: [ja_JP]
  version: 10.3.0.0 alpha - (1)
 Found support for locale: [ko_KR]
  version: 10.3.0.0 alpha - (1)
 Found support

Re: [VOTE] Army Brown as a committer

[Manish Khettry]

+1

Manish

- Original Message 
From: Mike Matrigali [EMAIL PROTECTED]
To: Derby Development derby-dev@db.apache.org
Sent: Tuesday, October 10, 2006 12:48:00 PM
Subject: [VOTE] Army Brown as a committer

This vote is for establishing Army Brown as a committer for Derby.
His JIRA id is:
Username:army
Full Name:A B
Email:[EMAIL PROTECTED]

[jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-883?page=comments#action_12432263 ] 

Manish Khettry commented on DERBY-883:
--

I think the issue can be closed. 

I'm not sure if we want to allow the use of grouping expressions in the having 
clause; i.e.

select c+1, count(*)
from t
group by c+1
having c+1  1;

I only have access to mysql, which doesn't allow this but does let you do

select c, count(*)
from t
group by c
having c  1;

If we do, then we need another bug or a subtask of this issue.

 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.1.0
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Fix For: 10.3.0.0

 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt, 883.patch7.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-883?page=all ]

Manish Khettry updated DERBY-883:
-

Attachment: 883.patch7.txt

Synced to rev 434408. Use the new JUnit test case/test setup classes. Passed 
derbylang.

 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.1.0
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Fix For: 10.2.1.0

 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt, 883.patch7.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-883?page=comments#action_12430672 ] 

Manish Khettry commented on DERBY-883:
--

I'm not sure what you mean by function changes-- one new function has been 
added to BaseJDBCTestCase (although it was added to the old BaseJDBCTestCase 
as well). The suite method in the GroupByExpressionTest.junit as well as the 
setUp/tearDown methods have changed slightly, but no new functions anywhere and 
no methods modified anywhere else.



 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.1.0
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Fix For: 10.2.1.0

 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt, 883.patch7.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-883?page=comments#action_12430681 ] 

Manish Khettry commented on DERBY-883:
--

no functional changes, so if you've fixed up patch 6 to work, then go with it. 

 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.1.0
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Fix For: 10.2.1.0

 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt, 883.patch7.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1624) use of direct column name rather than alias make aggregation fail (Hibernate depends on that)

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1624?page=comments#action_12428846 ] 

Manish Khettry commented on DERBY-1624:
---

Here is a description of the problem.

Derby rewrite queries involving group by's by adding an outer select and 
transforming the having clause to a where clause in the outer query, with some 
modifications. So in this case, given a query like:

select alias.x as c0, count(*) as c1
from foo alias 
group by alias.x having count(*)  0  ;

gets rewritten to:

select * from (select alias.x as c0, count(*) as c1 ... ) where generated_col  
0;

Subsequently, the * in the outer query gets expanded to:

select alias.c0, c1 from () where generated_col  0;

To me this seems a bit fishy-- it looks like alias is scoped in the subquery 
and not really visible in the outer query. For this reason, the following query 
also fails (users have to add a correlation name for subselects).

select alias.c0 from (select alias.x as c0 from foo alias) tabname;

Now the funny thing is that it passes without a having clause, the queyr works 
and thats because of the rather obfuscated 5 way search for column references 
in FromSubquery. Notice the huge difference in the search code between cases 2 
and 5. BTW, the code I pasted in the previous is not whats in the codeline-- I 
was playing aroudn with it, so please look at the checked in code).

One fishy thing I came across was the notion of a clause in a ValueNode; i.e 
IN_SELECT_LIST, IN_WHERE_CLAUSE, IN_HAVING_CLAUSE etc. First we only seem to 
use IN_SELECT_LIST and I do not see (unless I'm missing something) the last 
two. Second, what exactly are the semantics of the clause instance variable? IN 
a query like this, to which clause does the expression expr belong?

select .. from ... having c0  (select max(expr) ...);

Is expr in a having clause or a select clause? I think answering this would 
help because the column binding logic depends on this-- look at case 2, again: 
Should expr be considered to be in a having clause and therefore bound by this 
bit of code?

else if (generatedForGroupByClause  generatedForHavingClause 

 (columnsTableName != null || 
  columnReference.getClause() != 
ValueNode.IN_SELECT_LIST)) // 2
{

Anyway, I realize that I am posing more questions than providing solutions and 
that all of this is deep down in the innards of the query parsing/binding code 
which most of us are only incompletely familiar with but if you have any 
insights, please update the bug. 

I'd hate to see hibernate unusable with Derby due to bugs like this.




 use of direct column name rather than alias make aggregation fail (Hibernate 
 depends on that)
 -

 Key: DERBY-1624
 URL: http://issues.apache.org/jira/browse/DERBY-1624
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.1.1.0, 10.1.3.1
Reporter: Emmanuel Bernard

 Error: org.apache.derby.client.am.SqlException: Column 'MODEL0_.COL_0_0_' is 
 either not in any table in the FROM list or appears within a join 
 specification and is outside the scope of the join specification or appears 
 in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or 
 ALTER TABLE  statement then 'MODEL0_.COL_0_0_' is not a column in the target 
 table., SQL State: 42X04, Error Code: -1
 for
 select
 model0_.balance as col_0_0_,
 count(*) as col_1_0_ 
 from
 account model0_ 
 group by
 model0_.balance 
 having
 count(*)  1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1624) use of direct column name rather than alias make aggregation fail (Hibernate depends on that)

[Manish Khettry (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1624?page=comments#action_12428453 ] 

Manish Khettry commented on DERBY-1624:
---

This has to do with the way Derby rewrites querys with a groupby. What I find 
odd is that the query works without the having clause because the same rewrite 
is done for only group by's. I tracked it down to this bit of code in 
FromSubquery#findMatching column. So, when we are trying to bind model0_.name 
in the select list why look in different places (case 2 vs case 4) depending on 
whether there is a having clause or not?!

/* We have 5 cases here:
 *  1.  ColumnReference was generated to replace an aggregate.
 *  (We are the wrapper for a HAVING clause and the 
ColumnReference
 *  was generated to reference the aggregate which 
was pushed down into
 *  the SELECT list in the user's query.)  
 *  Just do what you would expect.  Try to resolve 
the
 *  ColumnReference against our RCL if the 
ColumnReference is unqualified
 *  or if it is qualified with our exposed name.
 *  2.  We are the wrapper for a GROUP BY and a HAVING 
clause and
 *  either the ColumnReference is qualified or it 
is in
 *  the HAVING clause.  For example:
 *  select a from t1 group by a having t1.a 
= 1
 *  select a as asdf from t1 group by a 
having a = 1
 *  We need to match against the underlying 
FromList and then find
 *  the grandparent ResultColumn in our RCL so that 
we return a
 *  ResultColumn from the correct ResultSetNode.  
It is okay not to
 *  find a matching grandparent node.  In fact, 
this is how we ensure
 *  the correct semantics for ColumnReferences in 
the HAVING clause
 *  (which must be bound against the GROUP BY list.)
 *  3.  We are the wrapper for a HAVING clause without a GROUP 
BY and
 *  the ColumnReference is from the HAVING clause.  
ColumnReferences
 *  are invalid in this case, so we return null.
 *  4.  We are the wrapper for a GROUP BY with no HAVING.  This 
has
 *  to be a separate case because of #5 and the 
following query:
 *  select * from (select c1 from t1) t, 
(select c1 from t1) tt
 *  group by t1.c1, tt.c1
 *  (The correlation names are lost in the 
generated FromSuquery.)
 *  5.  Everything else - do what you would expect.  Try to 
resolve the
 *  ColumnReference against our RCL if the 
ColumnReference is unqualified
 *  or if it is qualified with our exposed name.
 */
if (columnReference.getGeneratedToReplaceAggregate()) // 1
{
resultColumn = 
resultColumns.getResultColumn(columnReference.getColumnName());
}
else if (generatedForGroupByClause  generatedForHavingClause 

  columnReference.getClause() != 
ValueNode.IN_SELECT_LIST) // 2
{
if (SanityManager.DEBUG)
{
SanityManager.ASSERT(correlationName == null,
correlationName expected to be null);
SanityManager.ASSERT(subquery instanceof 
SelectNode,
subquery expected to be instanceof 
SelectNode, not  +
subquery.getClass().getName());
}

SelectNode  select = (SelectNode) subquery;

resultColumn = 
select.getFromList().bindColumnReference(columnReference);

/* Find and return the matching RC from our RCL.
 * (Not an error if no match found.  Let 
ColumnReference deal with it.
 */
if (resultColumn != null)
{
/* Is there a matching resultColumn in the 
subquery's RCL? */
resultColumn = 
subquery.getResultColumns().findParentResultColumn(

resultColumn);
if (resultColumn != null

Re: [VOTE] Approve coding conventions for the Derby project

[Manish Khettry]

I do think the space/tab issue causes headaches.We could just documentit, but I actually think we should reformat the code with respect to
tabstop and just move to spaces.I wish we were attacking the rootproblems causing people pain up front.What I see as problems are:1) space/tab issue is causing problems.Some tools just don't like 4space tabs.
2) do not make review/commit job harder by doing format changes alongwith real code changes.I do agree with Mike that tabs/spaces is whats causing headaches and if we fixed that first, we'd be better off. 
Anyway, as far as coding conventions go-- I'd rather that we adopt one and try and move the code to conform that. In my experience, if all (or most of the code) looks sort of similar, it is easier to read. I don't care where people put the brace, long as everyone puts it in the same place. This is just my experience-- if people think write clean code is a good enough convention, then so be it.

Re: [VOTE] Approve coding conventions for the Derby project

[Manish Khettry]

+1

I see that we're deferring tabs vs spaces and the {
position issue for later.

--- Andrew McIntyre [EMAIL PROTECTED] wrote:

 On 8/11/06, Kathey Marsden
 [EMAIL PROTECTED] wrote:
  This is a vote to define the coding conventions
 for the Derby project
  per the db project guidelines
 http://db.apache.org/source.html
  Vote closes  10:00am, Wednesday, August  15.
 
  [+1]  Adopt the coding convention described.
  [-1 ] Do not adopt the coding convention
 described.
 
  The conventions outlined below will be published
 on the wiki page
 

http://wiki.apache.org/db-derby/DerbyContributorChecklist
 
  Derby uses the Code Conventions for the Java
 Programming Language
 

(http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html)
 with these
  amendments:
   - space indentation (no tabs).
   - Derby does not discourage deferring variable
 declaration to the first
  use.
   - Lines should be limited to 80 characters
   - @author tags should not be used at all
 
  Note: There is a great deal of existing code that
 does not match this
  convention. Changes to existing code should match
 the surrounding code
  for readability, matching tabs or spaces as
 appropriate (see Tabs) .
  Patches should not have white space diffs. Code
 and diffs should be
  readable in  context.
 
 +1
 
 andrew
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[jira] Updated: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-883?page=all ]

Manish Khettry updated DERBY-883:
-

Attachment: 883.patch6.txt

svn update to revision 430199. Hopefully this patch will apply cleanly.



 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-883) Enhance GROUP BY clause to support expressions instead of just column references.

[Manish Khettry (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-883?page=all ]

Manish Khettry updated DERBY-883:
-

Attachment: 883.patch6.txt

Minor correction to previous patch.


 Enhance GROUP BY clause to support expressions instead of just column 
 references.
 -

 Key: DERBY-883
 URL: http://issues.apache.org/jira/browse/DERBY-883
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.2.1
 Environment: JDK 1.5.0_05
Reporter: Lluis Turro
 Assigned To: Manish Khettry
 Attachments: 883.patch.txt, 883.patch3.txt, 883.patch4.txt, 
 883.patch5.txt, 883.patch6.txt, 883.patch6.txt


 This select would return an error syntax on finding ( after month if group 
 by clause:
 select idissue, month(creation), year(creation), count(distinct idissue)
 where 
   
 group by idissue, month(creation), year(creation)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira