db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david myers <david.myers.scibearsp...@gmail.com>
Subject Re: Derby Key Words
Date Tue, 11 Dec 2012 22:16:36 GMT
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 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
>>>


Mime
View raw message