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 Mon, 15 Oct 2012 11:06:17 GMT
Hi David,

to access the patch I made, you need to download the patch attached to
the JIRA issue, e.g. this way

$ wget --no-check-certificate
$ cd <your Derby trunk sandbox of checked out from svn[1]>
$ patch -p0 < derbykeywords-1.diff

Hope this works!

[1] See here
$ svn checkout https://svn.apache.org/repos/asf/db/derby/code/trunk/

Since my patch only did part of what you wanted, I didn't commit it yet,
so feel free to build on it.
Good luck!


On 14.10.2012 20:28, david myers wrote:
> 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

View raw message