Hi Kathey,
This is definitely on my plate of to-do things. I will address this after I debug my tests and would definitelt wan to help people who start off.
thanks Shreyas
Kathey Marsden wrote:
Jack Klebanoff wrote:
Kathey Marsden wrote:
Shreyas Kaushik wrote:
Hi Kathey,
Thanks for all the guidance and help. Yes got one of my implicit questions right :-) of how to debug the tests in the framework. I would definitely do a wrie up for this and put it up on the web when I am comfortable doing this. Yes this sort of information would definitely hep users debug the tests in the framework.
Evan after running the tests with the properties that you had mentioned the tmp file did not have any major changes ( no stack tarces for the error I got ), except for a few warning message relating to empty tables.
One interesting I noticed is that the select statement in the test that is prior to this is, does a similar operation and the result fetches two rows. So I presume the delte should delete two rows am I missing something obvious here ?
I did a pass of code that I have changed, I just pull the correlation name from the query and pass it to the DeleteNode. Could this be a binding problem? Looks like that from the error I am getting. I will look at this aspect more, any more pointers/comments on my code changes will definitely help.
~ Shreyas
Kathey Marsden wrote:
Hi Shreyas,
I am glad you are back on the trail with this issue and have some ideas. I really can't answer your specific question at all because I don't know *what* SQL we are talking about here, but if after some more research, you are still stuck, feel free to post a question. Don't forget to include the five key ingredients to getting answers from busy people on the list.
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.
For this post I think you would have done a pretty good job with 4 and 5 if 1, 2, and 3 were here too. I think you forgot 1 and 2. below are some tips for step 3 to get a stack trace.
a) Create a small repro.sql script Take just enough sql to get the specific sql from step 1 working. (Usually some ddl some inserts and then the trouble maker) b) start ij with -Dij.exceptionTrace=true and execute the sql.
Here is an example. Looks like I need help with my select statement #:) $ java -Dij.exceptionTrace=true org.apache.derby.tools.ij ij version 10.1 ij> run 'repro.sql'; ij> connect 'jdbc:derby:wombat;create=true'; ij> create table mytab(i int); 0 rows inserted/updated/deleted ij> insert into mytab values(1); 1 row inserted/updated/deleted ij> selectoops from mytab; ERROR 42X01: Syntax error: Encountered "selectoops" at line 1, column 1. ERROR 42X01: Syntax error: Encountered "selectoops" at line 1, column 1. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
at org.apache.derby.impl.sql.compile.ParserImpl.parseStatement(ParserImpl.java:156)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:298)
at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107)
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:688)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:501)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:475)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:209) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:175) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55) at org.apache.derby.tools.ij.main(ij.java:60) ij>
As for reviewing your code so far, I am sorry, but I don't think I have time to do that right now. Just too busy, but perhaps someone else from the community can. I have noticed others from your company on the list. I know that a lot of times when I need a review, I ping someone that I work with and have pretty good results that way. Kathey
Another good place to look for debugging information is the derb.log file. When a test is run using the Derby test harness this file is found one level down from the test output. If the test output is in file dir/test.out then the log file is in dir/test/derby.log. The derby.log file has a record of the SQLExceptions, the statement that caused them, and the stack traces. I often look in derby.log first, though if the test does a lot of negative testing derby.log may be cluttered with a lot of expected SQLExceptions.
Jack Klebanoff
Excellent point Jack.
If you running outside of the test harness you probably want to put these in your derby.properties to get the errors in your derby.log
derby.language.logStatementText=true derby.stream.error.logSeverityLevel=0
Shreyas, I think your "How To Analyze a Test Failure" page is going to
be a big hit and a valuable resource to the community. It would be
great if you could get an initial draft posted to the list within the
next few weeks while you still have your fresh perspective. (I think
some of us that have been working on these kinds of issues for a while,
start to forget to mention the things that have become automatic.) Then over time folks can iterate over it, expand and improve. I'd be
more than happy to review and will try to gather together some more tips
for you. Over time you could produce a whole "How To" series for
beginners.
On your questions, I want to make sure I am in no way discouraging
questions, but just before you hit send take a look at the post from
the audience's perspective. A good question to ask yourself is, "If I
were a Derby expert, could I effectively answer this question given the
information provided?" If we are talking about the behaviour of a
particular SQL statement, it is really critical to include the SQL
statement in question and probably the ddl that is necessary to run
it. Typically, your audience wouldn't have time to apply an entire
in progress patch, figure out what you are doing. So, you have to
summarize effectively, it is usually not the quantity but the quality of
information that is key. Let's take a look at your refeactions1 diff again, Here is the diff you were asking about for those just joining.
** 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.
Here is how you can form your next question on this issue so that busy people in the community might able to help. Fill in the <>'s with the missing information.
I am implementing delete with alias, < insert SQL Syntax from the SQL spec here >
I almost have it working but am stuck on this case. < insert general description of the case in question here>
This was disallowed before becuase <... >and gave a Syntax error. Now it <{should work | should still give a syntax error | something
else}> , but with my changes I get an error that the column is not
in any table in the from list.
My general strategy in this case was to < ....> pull the correlation name from the query and pass it to the DeleteNode. <....>
I thought in this case there might be a binding problem because <...>. In debugging that I found <....>
Here is an example of the SQL for this case and the trace I get with my changes.
create table <...>. insert into <....> <select | delete ...>
< A question that someone could answer given just the information you have provided >
It's ok to post your patch so far for reference, but you can't really expect that anyone is going to have time to apply it and debug the problem themselves. You can see I never even needed to know that refactions1 failed, but I really do need to know what SQL you are trying to execute and how you expect it to behave. The great thing about composing your question in this way is that you will probably find out what's wrong yourself along the way #:).
Dan, was mentioning an article on "How To Ask Questions the Right Way", but I am having trouble finding it. Dan could you post a link?
Kathey
