db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Derby Key Words
Date Tue, 04 Dec 2012 16:57:46 GMT
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?


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
>>>>>>>>> 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
>>>>>>>> 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
>>>>>>>   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
>>>>>>> look at but shouldn't be changed.
>>>>>>> I think there may be an exclipse plugin for javacc but I have
>>>>>>> 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
>>>>>> 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
>>>>>> 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
>>>>>> 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?
>>>>>> Junit 4 you place a <@Test> token on the line before the method
>>>>>> you want the method to run, along with annotations like <@before>
>>>>>> there are any that need to come before other stuff.
>>>>>> Also my test classes have only really had 1 method I want to run
>>>>>> a time, so I just comment out the <@Test> annotation to effectively
>>>>>> turn off the method.
>>>>>> Please add your comments.
>>>>>> David

View raw message