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 Thu, 13 Dec 2012 20:10:52 GMT

Sounds fair to me.


On 12/12/12 14:30, Rick Hillegas wrote:
> 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".
> Thanks,
> -Rick
> 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
>>>>>> checked out from svn[1] > before doing wget (surely I'll end up
>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> person project?
>>>>>>>> sorry I digress....
>>>>>>>> I've located the files that I think I'm going to need.
>>>>>>>> EmbededDataBaseMetaData[40].java and TestDBMetaData.java
>>>>>>>> I 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>>> 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 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
>>>>>>>>>> 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 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
>>>>>>>>>> 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 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
>>>>>>>>>> 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
>>>>>>>>>> <@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