Yes, sorry, you'd need to do that or use a path for the patch file, of course. Dag
david myers <[email protected]> wrote: >Dag, > >thanks for the info. I'll have a try with that later on. >One thing though, should I not be in my < derby trunk sandbox of checked >out from svn[1] > before doing wget (surely I'll end up with it in the >wrong place)... I'm probably showing my ignorance about wget and svn as >I've not done this sort of stuff before ;) > >Not that it matters, I'll check it out later on.... > >David > >On 15/10/12 13:06, Dag Wanvik wrote: >> 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 >
