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 Wed, 12 Dec 2012 13:30:50 GMT
Hi David,

Thanks for continuing to think about this issue. Dag's solution looks 
good enough to me. I don't see any compelling reason to also expose this 
functionality via a second api, namely, a Derby-specific extension to 
the JDBC metadata. I'm glad that you want to contribute to Derby. At 
this point I think that a better introductory task would be to pick one 
of the Derby JIRA issues which is marked "Newcomer".


On 12/11/12 2:16 PM, david myers wrote:
> On 04/12/12 22:33, Dag Wanvik wrote:
>> 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
> Hi Rick and Dag,
> Dag's solution is exceedingly complete, but like Dag mentions I am 
> putting the finishing touches on a DataBaseMetaData method to kick out 
> the info (in the form of a table as per your original suggestion).
> Currently it seems to 'work', but I have a few 'niggles' that I want 
> to solve, mainly revolving around the test(s) I'm writing.
> Currently my metadata method is in its own class that inherits from 
> the 'proper' one, so no danger of me breaking something else on the 
> way (eventually if its good we can simply copy / paste it back into 
> the parent).
> The same is true for my test class.
> Also I'm not sure how to test for the presence of the JJ file and 
> Dag's patch on which I obviously rely, I understand (sort of) how Dag 
> uses the build paths to find the file in his patch, but I'm not sure 
> how to code these into a test, i'm sure they are in a test somewhere, 
> just for the moment I haven't 'seen' them, or do I even need to worry 
> about this ? is simply listing them in my < 
> getDerbyKeyWordsTest_app.properties > going to be sufficient ? again 
> how to I give a location based on the derbyHome or similar in this file?
> If you can point me to a good example test class that does this sort 
> of thing, I'll work my way through it and use the same model for my 
> test class.
> Personally I just want to give a good test with sensible responses 
> when they fail if the files I rely on strangely go missing or move to 
> another location.
> I'll try to get back with the exact problems I seem to be facing, 
> which for the moment are rather varied, and probably linked to my 
> setup of Eclipse... i'm getting there slowly though.
> I just need to find a few extra hours somewhere... especially as the 
> wife has decided it is time to redecorate the bedroom ;).
> Speak again soon
> David
>>> 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
>>>>>> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> will
>>>>>>> put my < getDerbyKeyWords() > method and test.
>>>>>>> Rik thanks for waving your hands about the compile time tool.
>>>>>>> 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
>>>>>>> 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
>>>>>>>> (part
>>>>>>>> of) the job. It uses the actual lists from sqlgrammar.jj
>>>>>>>> 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
>>>>>>>> provide
>>>>>>>> those functions, I think, if we decide that's the way to
>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> SQLParserConstants.java interface
>>>>>>>>> This inner class has a single method that grabs all of
>>>>>>>>> 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
>>>>>>>>> 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,
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> test? In
>>>>>>>>> Junit 4 you place a <@Test> token on the line before
>>>>>>>>> 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
>>>>>>>>> effectively
>>>>>>>>> turn off the method.
>>>>>>>>> Please add your comments.
>>>>>>>>> David

View raw message