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
Rik,

Sounds fair to me.

David.


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