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 https://issues.apache.org/jira/secure/attachment/12544418/derbykeywords-1.diff $ cd <your Derby trunk sandbox of checked out from svn[1]> $ patch -p0 < derbykeywords-1.diff Hope this works! [1] See here http://db.apache.org/derby/dev/derby_source.html#Development+trunk $ 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! Thanks, Dag 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 >
