db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik" <dag.wan...@oracle.com>
Subject Re: Derby Key Words
Date Mon, 15 Oct 2012 22:10:26 GMT
Yes, sorry, you'd need to do that or use a path for the patch file, of course.

david myers <david.myers.scibearspace@gmail.com> wrote:

>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....
>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
>>>>>>>> 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
>>>>>>> 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
>>>>> 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 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