db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Bouschen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-245) JPOX must throw JDOUserException for queries specifying having clause refering fields which are not part of the result clause.
Date Tue, 03 Jan 2006 21:42:15 GMT
    [ http://issues.apache.org/jira/browse/JDO-245?page=comments#action_12361678 ] 

Michael Bouschen commented on JDO-245:
--------------------------------------

A lot of comments, I'll try to give answers.

CLR:  There is only one thing wrong with this query: the HAVING clause is not a boolean expression.
It's ok to have SUM(salary) in the SELECT clause because you can SELECT terms that are either
in the GROUPING clause or are aggregates.

MBO: I think the HAVING clause "HAVING firstname" is invalid for two reasons: it is not a
boolean expression and uses a field firstname w/o aggregate that is not part of the grouping.
These are the two errors Andy and I were referring to. 

CLR: I think this should be changed to AVG(weeklyhours) to be valid. Then the test case is
only testing the HAVING error. 

MBO: I already changed the negative test to
  SELECT department, AVG(weeklyhours) FROM Employee GROUP BY department HAVING firstname
when fixing the positive test of class Having (see JDO-244).

CLR: Yet another comment. The title of this JIRA is the HAVING clause containing fields that
are not part of the result clause. Actually, it's legal for any aggregate expression to be
in the HAVING clause regardless of whether it is in the result.

MBO: I think the title of this JIRA is misleading. It should talk about a missing exception
for an invalid HAVING clause and should not mention the result clause at all. Maybe the test
class Having should be moved from package result to a different package (e.g. jdoql).

CLR: So maybe we need another positive test for HAVING that has an expression that isn't contained
in the SELECT clause.
e.g. SELECT department, AVG(weeklyhours) FROM Employee GROUP BY department HAVING COUNT(personid)
> 1

MBO: Yes, good idea. I will add this query. 

CLR: And another negative test for HAVING that uses a term that's not an aggregate.
SELECT department, AVG(weeklyhours) FROM Employee GROUP BY department HAVING middlename !=
NULL

MBO: OK, then we are back to the original negative query which had a HAVING clause: HAVING
firstname = 'emp1first'. But I can add this, too.

> JPOX must throw JDOUserException for queries specifying having clause refering fields
which are not part of the result clause.
> ------------------------------------------------------------------------------------------------------------------------------
>
>          Key: JDO-245
>          URL: http://issues.apache.org/jira/browse/JDO-245
>      Project: JDO
>         Type: Bug
>   Components: tck20
>     Reporter: Michael Watzek
>     Assignee: Andy Jefferson

>
> The test case Having fails for the query below. Query compilation is expected to throw
a JDOUserException because the having clause contains field firstname which is not part of
the result clause.
> 14:22:53,437 (main) DEBUG [org.apache.jdo.tck] - Compiling API query: SELECT department,
SUM(salary) FROM org.apache.jdo.tck.pc.company.Employee GROUP BY department HAVING firstname
== 'emp1First' 
> 14:22:53,453 (main) DEBUG [org.apache.jdo.tck] - Query compilation must throw JDOUserException:
null
> 14:22:53,453 (main) INFO  [org.apache.jdo.tck] - Exception during setUp or runtest: 
> junit.framework.AssertionFailedError: Assertion A14.6.10-2 (Having) failed: 
> Query compilation must throw JDOUserException: null
> 	at junit.framework.Assert.fail(Assert.java:47)
> 	at org.apache.jdo.tck.JDO_Test.fail(JDO_Test.java:546)
> 	at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:915)
> 	at org.apache.jdo.tck.query.QueryTest.compile(QueryTest.java:878)
> 	at org.apache.jdo.tck.query.QueryTest.compileAPIQuery(QueryTest.java:793)
> 	at org.apache.jdo.tck.query.result.Having.testNegative(Having.java:120)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:324)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.textui.TestRunner.doRun(TestRunner.java:116)
> 	at junit.textui.TestRunner.doRun(TestRunner.java:109)
> 	at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
> 	at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)

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


Mime
View raw message