Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 6465 invoked from network); 8 Apr 2005 04:33:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Apr 2005 04:33:09 -0000 Received: (qmail 80851 invoked by uid 500); 8 Apr 2005 04:33:09 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 80823 invoked by uid 500); 8 Apr 2005 04:33:08 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 80807 invoked by uid 99); 8 Apr 2005 04:33:08 -0000 X-ASF-Spam-Status: No, hits=1.8 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from e3.ny.us.ibm.com (HELO e3.ny.us.ibm.com) (32.97.182.143) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 07 Apr 2005 21:33:07 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j384X42L000409 for ; Fri, 8 Apr 2005 00:33:04 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j384X4Xs236384 for ; Fri, 8 Apr 2005 00:33:04 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j384X4wY028417 for ; Fri, 8 Apr 2005 00:33:04 -0400 Received: from [127.0.0.1] (sig-9-48-122-68.mts.ibm.com [9.48.122.68]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j384X21Y028388 for ; Fri, 8 Apr 2005 00:33:03 -0400 Message-ID: <4256097B.8030706@sbcglobal.net> Date: Thu, 07 Apr 2005 21:32:59 -0700 From: Kathey Marsden User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: Re: [jira] Commented: (DERBY-156) Delete with alias on column fails References: <528069045.1109731548838.JavaMail.jira@ajax.apache.org> <42254445.3080306@Sun.com> <424FFBF7.8050301@Sun.com> <42513C80.60502@Sun.com> <4252ADD1.8040006@sun.com> <4254CDEB.5000404@sun.com> <4254D7A3.5020908@sbcglobal.net> <42554674.8000809@sun.com> In-Reply-To: <42554674.8000809@sun.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Shreyas Kaushik wrote: > Please see inline. > > Kathey Marsden wrote: > >> Shreyas Kaushik wrote: >> >> >> >>> Can somebody reply on this? >>> >>> ~ Shreyas >>> >>> Shreyas Kaushik wrote: >>> >>> >>> >>>> Did any1 have a chance to look at this? >>>> >>>> ~ Shreyas >>>> >>>> Shreyas Kaushik wrote: >>>> >>>> >>>> >>>>> I did some changes to sqlgrammar.jj file to make a fix for this. >>>>> With the patch , the following cases are taken care : >>>>> 1) delete from where >>>>> . = >>>>> 2) delete from AS where >>>>> . = >>>>> >>>>> But when I ran derbyall I had a couple of failures. >>>>> I am attaching the test failure diffs here as well. >>>>> >>>>> Please comment. >>>>> >>>>> ~ Shreyas >>>>> >>>> >> >> What did you find in anlalyzing your test failures? I have not looked >> at your diffs specifically, but one thing I have found helpful is that >> often if there is a trace it is in the .tmp file, and has been filtered >> out of the .out file. > > No, nothing has been filtered out. > >> Take a look at the failures and try to >> determine how they might relate to your changes and let us know if you >> have some more specific questions, what is failing how you think it may >> or may not be related to your change. >> >> > w.r.t floattypes I don't see how my changes could have made any impact > there. > But the tests in refActions1 that have failed were earlier failing as > there was no correlation name handling for > delete statements. These were giving a different error as the diffs show. > But now with the correlation name handling fixed ( hopefully ;-) ) I > don't know whether the queries that are > erroring out are correct ? It could be that I might have also missed > something. I want people here to have a look at it > so that they might spot something that I may have missed. > > ~ Shreyas > >> Kathey >> >> >> >> >> >> > > Hi Shreyas, Sounds like you are really stuck on this thing so I would like to try to help. Let me take a look at this refActions1 diff you sent. ** Start: refActions1 jdk1.5.0 derbyall:derbylang 2005-04-04 15:53:53 *** 6009 del < ERROR 42X01: Syntax error: Encountered "d" at line 1, column 26. 6009a6009 > ERROR 42X04: Column 'DB2TEST.DEPT.DNO' is not in any table in the FROM list or it appears within a join specification and is outside the scope of the join specification or it appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'DB2TEST.DEPT.DNO' is not a column in the target table. > Hmmm, we used to perform some sql command, and got a syntax error and now we perform the same sql command and get a different error. I can't really tell from this diff whether considering the changes you made ... a) The syntax error is correct. b) The new error is correct c) That sql command (whatever it is) should have completed just fine. It seems to me maybe you have a bigger question of. "How do I debug a test failure"? And that I think is an excellent question, because our test harness is not always the easiest thing to figure out. So here are some quick notes on the topic to get you started. Nothing formal, so forgive typos and such. I hope they help you get past your current sticking point. I also hope that after you iterate over this process a few times and improve upon it, you will consider making a short write up for the web site on how to debug test failures. I think new folks would find it useful. I'll just stick to embedded here since that is the problem at hand, but certainly there are other tips and tricks for network server, so I would be happy to provide those if you are interested in making a web page with this info. How to debug a test failure. 1) Run the test. take a look at ${derby.src}/java/testing/README for all sorts of good info on tests). I think I would run this test something like this. java -Dij.exceptionTrace=true -Dkeepfiles=true org.apache.derbyTesting.functionTests.harness.RunTest lang/refActions1.sql For network server add -Dframework=DerbyNet (OK 1 network server tip.) 2) Do a visual diff of the ouptut with the canon It will give you more context in approaching the problem. In the test output directory you will see refactions1.out (filitered test output) refactions1.tmp (unfiltered test output - this one should have a trace) To get the most information, I usually initially vdiff the tmp file with the canon which is checked in under java/testing/org/apache/derbyTesting/functionTests/master/ or appropriate framework or jdk subdirectory. 3) Identify the sql statement or java code causing the diff. For sql scripts this is usually pretty obvious. For java programs you have to look at the test source to figure out what is going on. 4) Evaluate the diff. This of course starts the tricky and interesting part. Look carefully at the sql command or java code that caused the diff. Think about what it should do and how it relates to your change. Decide what you think the right behaviour should be. a) The old behaviour b) The new behaviour c) something else If you have a trace, look at the the trace and see if it holds any clue. If you are lucky it passes right through that code you changed. Often it is helpful to put that one sql command or bit of java code in a separate script or stand alone program, so you can evaluate it independently outside of the harness and evaluate in the debugger. Common results of the evaluation phase are: a) An error in your code. b) Someone elses test failure all together. Good to keep a clean client for testing this. c) A master update. Be careful with this one. make sure you have a valid reason to update a master. Be especially cognizant of backward compatibility. We don't want any real or perceived regressions to catch us by surprise. Two good questions to ask your self and then answer when you post your patch. 1) What is my valid reason for updating this master. 2) Might someone be surprised by this difference and perceive it as a regression? 5) Resolve the issue. Here are some possible actions based on your evaluation in step 4 a) An error in your code. Fix it #:) b) Someone else's test failure all together. Look at the recent checkins and try to guess the culprit and post. (See Dan's mail earlier today entitled jdbcapi/testRelative failing & Derby-186) for an example of this.) c) A master update. update the master and make sure you include an explanatio in your patch. If you get stuck along the way, please post to the list, but make sure you include. 1) The small bit of sql or java code in question. 2) A description of the old and new behaviour and what you think the right behavior should be. 3) The stack trace if there is one. 4) What you have learned so far from your own evaluation of 1-3 above. 5) A specific question that is not going to take a lot of research for someone to answer that you think might send you back along your way if answered. Hope this helped. Good luck and happy debugging. I really do hope you will consider writing up the process as you become comfortable with it. Thanks Kathey