db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david myers <david.myers.scibearsp...@gmail.com>
Subject Re: Derby Key Words
Date Sun, 14 Oct 2012 18:28:06 GMT
Hi all,

must apologise for being so quiet,busy with my 'real' job etc. However 
this doesn't mean I've been ignoring what I want to do.

I've been reading around the code to determine the files that I am going 
to require to initiate this little modification. I think I am begining 
to understand how things work a little better. Firstly however I want to 
ensure I have well understood.

The file sqlgrammar.jj is read by javacc and creates a bunch of other 
.java clases.

SQLParserConstants.java is one of these files, it is an interface that 
is implemented by the SQLParser class (also created from sqlgrammar.jj).

So if I can modify sqlgrammar.jj I could 'inject' into the SQLParser 
class a method that return the list of static final members (stored in 
the tokenImage string array member, so in fact I could just return this 
member).

My problems currently now revolve around the following.

DAG has created a method that reads the sqlgrammar.jj file directly and 
creates the Keywords.java file. I can't seem to find this in my source 
tree, is this related to needing the specific DERBY-3256 checkout. I've 
tried using the SVN plugin for eclipse to find this checkout, but so far 
to no success. Any chance someone could walk me through doing this from 
the CLI (ubuntu 12.04).

Should I mention at this point I'm rather new to SVN (actually version 
control in general!), did I say previously this is my first multi person 
project?
sorry I digress....

I've located the files that I think I'm going to need. 
EmbededDataBaseMetaData[40].java and TestDBMetaData.java where I will 
put my < getDerbyKeyWords() > method and test.

Rik thanks for waving your hands about the compile time tool. I think 
this may be what I need to implement my < getTokenImage() > so any 
pointers would be great.

Once I've got the method working locally I guess I'll need to create a 
bug or something, that points to the various JIRA issues, and then solve 
it.... but for me that comes a little later. For now I want to write the 
method into my local tree only. Then recompile, test ... blah blah blah...

Is this an acceptable way in which to proceed? Any suggestions advice 
are welcome.

Thanks in advance.

David.




On 10/09/12 01:23, Dag Wanvik wrote:
> Hi,
>
> 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.
>
> Dag
>
> 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


Mime
View raw message