On 05/09/12 06:25, Katherine Marsden wrote:
On 9/4/2012 7:44 PM, Bryan Pendleton wrote:
I've had success in pointing Eclipse to the source code that I have
built. I have had a nice look around for the file that I am
interested in, which from the previously mentioned JIRA issues etc
suggest a file called sqlgrammar.jj
only problem is I can't find it!
It's possible that Eclipse doesn't grok '.jj' files in its normal
configuration.
The file should be in your source tree as:
./java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
There is a compiler-generation tool that processes this file during
the Ant build of Derby and generates Java source from the grammar.
The tool that generates the java code for the parser from
sqlgrammar.jj is Javacc. The generated code is in
generated/java/org/apache/derby/impl/sql/compile which is fun to look
at but shouldn't be changed.
I think there may be an exclipse plugin for javacc but I have never
used one.
Kathey
Hello again all,
Sorry I hate to pollute the thread, but I want to ensure that I do
things 'the apache way' and not just my way!
So I need a little advice.
First some info.
The file as mentioned by Bryan has been located. Thanks to Kathey's
pointer I have found the actual java file that is going to be of
interest to me.
The files that I think are going to be informative are:
SQLParserConstants.java ~ this is the interface
SQLParser ~ a class file that implements this interface is
This file is found in Source Folder: generated/java/
package:
org.apache.derby.impl.sql.compile
So now it is a question of testing out my idea !
The interface <SQLParserConstants.java> has no methods, only static
final "int" members.
This leads me to a potential solution as follows:
Create a method that has an inner class that implements the
SQLParserConstants.java interface
This inner class has a single method that grabs all of the members and
inserts them into a arrayList<String> - for "equal time access" to the
values.
We can then access this arrayList and compare a passed in value to
determine if the value exists in the list.
My first idea is to test the method within a test class, a good
candidate for its location is the following I think.
TestDbMetaData
located in source folder java/test
package ~ org.apache.derbyTesting.functionTests.tests.jdbc4
Or alternatively I can create a separate test class to test the idea
(which would probably be my preference to start with, then once it works
as I would like it to everything can be copied into a more sensible
location.
Once I have the method functioning I could add it into a specific
package (probably databaseMetaData), then test it in situ.
Does the above seem like a valid process?
I have a few queries about the test suite.
I have been using Junit4 from within eclipse, and I'm aware that you use
Junit 3.8. I notice that with your test files you don't use annotations
for the methods. With the exception of the setup and tear down methods,
how do you control the flow through the test? In Junit 4 you place a
<@Test> token on the line before the method if you want the method to
run, along with annotations like <@before> if there are any that need to
come before other stuff.
Also my test classes have only really had 1 method I want to run at a
time, so I just comment out the <@Test> annotation to effectively turn
off the method.
Please add your comments.
David
