On 04.12.2012 17:57, Rick Hillegas wrote: > Hi David, > > I have added a comment to DERBY-3256. I think that Dag's solution > looks complete and reasonable. I recommend that it be committed and > documented. Does his solution not solve your original problem? > Thanks for looking at the patch, Rick. I think David wants to extend this solution so one could get these keywords via DataBaseMetaData?
Thanks, Dag > Thanks, > -Rick > > On 11/26/12 2:16 PM, david myers wrote: >> Hello All, >> >> As always first off I should appologise for being quiet, i've been >> reading through the code and I think I start to understand things >> that were not very clear to me previously. >> >> My current situation is now the following >> >> I've got myself well sorted out. >> >> Eclipse now has a 'handle' on the svn repo (copied locally of >> course), and I've been able to grab Dag's patch and it to this, all >> from inside eclipse (which I'm pleased worked out). >> >> Dag's code is interesting, very cool. >> >> I feel my next steps are as follows... >> >> I need to write a new class (or extend an existing one). I guess >> something in DB MetaData. But what and where? >> Then I need to test it. Where should I put my test class (or again >> should I add the test to a class that already exists. >> >> I feel that I am now ready to implement this. I just need some >> pointers of how to run my individual test case (I make the assumption >> that as I'm not going near anything else in the first instance I >> shouldn't break it (that is also why I propose a new subclass of one >> of the existing dbMetaData classes). >> >> I hope to become a little more active before christmass >> >> David. >> >> >> On 15/10/12 20:48, david myers 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 >>> >> >> >
