You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Nirmal Fernando <ni...@gmail.com> on 2010/08/19 14:21:51 UTC

Reconsidering an entry in orderby.out

Hi All,

I found the following test at line 1810 in
java/testing/org/apache/derbyTesting/functionTests/master/orderby.out:

ij> -- Ordering by an expression involving an unselected column is not.
However,
-- Derby does not currently enforce this restriction. Note that the answer
-- that Derby returns is incorrect: Derby returns two rows with duplicate
-- 'name' values. This is because Derby currently implicitly includes the
-- 'age' column into the 'distinct' processing due to its presence in the
-- ORDER BY clause. DERBY-2351 and DERBY-3373 discuss this situation in
-- more detail.
select distinct name from person order by age*2;
NAME
----------
John
Mary
John

As per discussions at
Derby-4371<https://issues.apache.org/jira/browse/DERBY-4371>this query
should not be allowed, since column "age" is not there in the
select clause.

What you think? I think we should correct this test.

Thanks.

-- 
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.

Fwd: Reconsidering an entry in orderby.out

Posted by Nirmal Fernando <ni...@gmail.com>.
Thanks Bryan for the explanation!!

On Thu, Aug 19, 2010 at 8:30 PM, Bryan Pendleton
<bp...@gmail.com> wrote:
>
> > I found the following test at line 1810 in
> > java/testing/org/apache/derbyTesting/functionTests/master/orderby.out:
>
> I agree, the query should not be allowed.
>
> The challenge for DERBY-4371 is to reject the illegitimate queries
> without rejecting any valid queries.
>
> You might wonder why our test suites contain queries which demonstrate
> that Derby is currently returning the wrong result.
>
> Each time we encounter or think up a new interesting query like
> this, we try to put the query into our test suite, so that, over time,
> the test suite becomes richer and richer with more and more varieties
> of queries.
>
> So in this particular case, we added this query, and this test case, to
> orderby.out, as part of the DERBY-3373 changes. Even though the answer
> is wrong, it is still helpful to have the query in the test suites.
>
> That way, when a subsequent change such as DERBY-4371 comes along, it
> can change the test to demonstrate the improved results.
>
> So, yes, it would be fine to change this test case to produce an
> error, if that is the result of your work on DERBY-4371.
>
> thanks,
>
> bryan
>



--
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.



--
Best Regards,
Nirmal

C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.

Re: Reconsidering an entry in orderby.out

Posted by Bryan Pendleton <bp...@gmail.com>.
 > I found the following test at line 1810 in
 > java/testing/org/apache/derbyTesting/functionTests/master/orderby.out:

I agree, the query should not be allowed.

The challenge for DERBY-4371 is to reject the illegitimate queries
without rejecting any valid queries.

You might wonder why our test suites contain queries which demonstrate
that Derby is currently returning the wrong result.

Each time we encounter or think up a new interesting query like
this, we try to put the query into our test suite, so that, over time,
the test suite becomes richer and richer with more and more varieties
of queries.

So in this particular case, we added this query, and this test case, to
orderby.out, as part of the DERBY-3373 changes. Even though the answer
is wrong, it is still helpful to have the query in the test suites.

That way, when a subsequent change such as DERBY-4371 comes along, it
can change the test to demonstrate the improved results.

So, yes, it would be fine to change this test case to produce an
error, if that is the result of your work on DERBY-4371.

thanks,

bryan