db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag Wanvik <dag.wan...@oracle.com>
Subject Re: Derby Key Words
Date Sun, 09 Sep 2012 23:23:13 GMT

I added an experimental patch to DERBY-3256 which seems to do (part of) 
the job. It uses the actual lists from sqlgrammar.jj to generate 
Keywords.java at compile time, and wraps those in a table function.  
There is no metadata function in it but it could be used to provide 
those functions, I think, if we decide that's the way to go.


On 05.09.2012 23:28, david myers wrote:
> 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

View raw message