db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag Wanvik <dag.wan...@oracle.com>
Subject Re: Derby Key Words
Date Tue, 04 Dec 2012 21:33:56 GMT

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

> 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