Re: Derby Key Words

[david myers <da...@gmail.com>]

On 31/08/12 15:00, Rick Hillegas wrote:
> On 8/30/12 2:56 PM, David Myers wrote:
>> ...
>> I think your solution of a table function should work well enough.
>> > From the few table functions I have used, I notice that I was also
>> able to get the same info from a join of 2 system tables. Is this how
>> they generally work (I call the function and an SQL command runs in
>> the background)?
> Hi David,
>
> What you just described sounds more like a view than a table function 
> to me. Table functions are useful for examining data that comes from 
> external databases or from non-relational sources. Turning a list into 
> a table sounds like a good use of table functions to me.
>> Also would it not make some sense to have a method
>> within the databaseMetaData object thqt would return either the list
>> of values (after calling the new function) or take a string argument
>> and return true (the argument is equivalent to a key word) or false.
>>
> This is an interesting approach and might be cheaper to implement. I 
> think we would only need to add the new method to Derby's embedded 
> implementation of DatabaseMetaData. We would need to make sure that 
> the new method had a name which the JDBC expert group would never want 
> to use. The advantages of a table function (can be used in queries, 
> can be used across the network by JDBC client apps) could be had by 
> wrapping the Derby DatabaseMetaData in something like the DBMDWrapper 
> class attached to https://issues.apache.org/jira/browse/DERBY-3973.
>
> Thanks,
> -Rick
Hello again all.

Things are progressing.... sort of ;)

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!
This file holds the 2 methods, that I am interested in.
It seems to me that the data must already be locked away somewhere in 
derby, but I haven't yet found where. I haven't even found a 
databasemetadata.java file... yet ?

I guess I'm missing something somewhere...

David

Re: Derby Key Words

[david myers <da...@gmail.com>]

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

Re: Derby Key Words

[Rick Hillegas <ri...@oracle.com>]

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

Re: Derby Key Words

[Dag Wanvik <da...@oracle.com>]

On 11.12.2012 23:16, david myers wrote:

> need to worry about this ? is simply listing them in my <
> getDerbyKeyWordsTest_app.properties > going to be 

Just for your FYI, the *_app.properties stuff is part of our old testing
harness, nowadays we build tests in JUnit only.
The test directories contain a mix of old test harness tests (we're
always trying to convert the rest of those) and JUnit tests. Almost all
test files named <name>Test.java (note the capital "T") are examples of
JUnit based tests.

Thanks,
Dag

Re: Derby Key Words

[david myers <da...@gmail.com>]

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

Re: Derby Key Words

[Dag Wanvik <da...@oracle.com>]

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

Re: Derby Key Words

[Rick Hillegas <ri...@oracle.com>]

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

Re: Derby Key Words

[david myers <da...@gmail.com>]

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
>

Re: Derby Key Words

[david myers <da...@gmail.com>]

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

Re: Derby Key Words

[Dag Wanvik <da...@oracle.com>]

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
>

Re: Derby Key Words

[david myers <da...@gmail.com>]

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

Re: Derby Key Words

[Dag Wanvik <da...@oracle.com>]

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

Re: Derby Key Words

[david myers <da...@gmail.com>]

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

Re: Derby Key Words

[Rick Hillegas <ri...@oracle.com>]

Hi David,

Some comments inline...

...
> re your comment of String constants in an array. I found the same 
> thing in the interface.
>
> It has just occured to me that, as we use a database, maybe a 
> resultSet may be the thing to return , I've come full circle to 
> understanding your original idea of a 'Table Function'. But I would 
> still think that a function in DatabaseMetaData would be good.
>
> Along these lines... it should take a String argument that is the word 
> being tested, and return true [word is in list] or false [word is not 
> in the list]. I propose to call the method prototype to be something 
> like getAllDerbyKeyWords(String wordToTest) . Hopefully as it has the 
> word 'Derby' in it the SQL people are unlikely to ever use is in the 
> standard! Although maybe there would be an argument to propose a new 
> method of getAllKeywords() to the standard, that each driver vendor 
> could implement and would have the same / similar functionality - 
> delusions of grandeur ;)
The presence of Derby in the function name sounds good to me. I agree 
that that should prevent the JDBC spec from encroaching on this 
function. I'm afraid I don't understand the usefulness of the String 
argument. Having a no-arg function which returns all of the words sounds 
good enough to me. The restriction to a single string can be 
accomplished by this query against the resulting table function:

select keyword from table( getAllDerbyKeyWords() ) t where t.keyword = 
'wordToTest'

>
> But how to turn that String Array into a Table is fairly simple (I'd 
> declare a temp table), and then make a select on it to get a 
> resultSet. However is there a way to skip the table step and jump 
> straight to a result set (its a bit of a leading question, and I 
> haven't searched for an answer anywhere yet, so unless you know off 
> the top of your head no need to answer straight away).
The table function can just be an extension of 
org.apache.derby.vti.StringColumnVTI. All you have to implement are 3 
methods: next(), close(), and getRawColumn().

Hope this helps,
-Rick
>
> David
>

Re: Derby Key Words

[david myers <da...@gmail.com>]

On 05/09/12 23:29, Rick Hillegas wrote:
> On 9/5/12 7:02 AM, David Myers wrote:
>> Hello all,
>>
>> Bryan, thanks for the info (although I was using 'locate' on my ubuntu
>> box, and it still didn't find it ?) I'll have a look tonight.
>>
>> Kathey, I don't intend to modify the file, just grab the contents, if
>> possible an without using a file Input Stream
> Hi David,
>
> Note that the keywords appear in an array of String constants that are 
> generated by javacc into 
> trunk/generated/java/org/apache/derby/impl/sql/compile/SQLParserConstants.java. 
> That may be a more straightforward way to get your hands on the 
> keywords but it may require understanding more about how the generated 
> grammar behaves and it may involve building a compile time tool which 
> scrapes the keywords out of SQLParserConstants. I am waving my hands, 
> of course.
>
> Hope this helps,
> -Rick
>> I also noted that the DatabaseMetaData.getSQLkeywords() actually has a
>> hard coded list of words! I have no problem with that in the first
>> instance, but I'm sure that the engine doesn' check every word with a
>> call to this method before throwing an error!
>>
>> I need to keep looking...I'll keep you all posted.
>>
>> D
>>
>> On Wed, Sep 5, 2012 at 6:25 AM, Katherine Marsden
>> <km...@sbcglobal.net>  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
>>>
>>>
>
Rick,

re your comment of String constants in an array. I found the same thing 
in the interface.

It has just occured to me that, as we use a database, maybe a resultSet 
may be the thing to return , I've come full circle to understanding your 
original idea of a 'Table Function'. But I would still think that a 
function in DatabaseMetaData would be good.

Along these lines... it should take a String argument that is the word 
being tested, and return true [word is in list] or false [word is not in 
the list]. I propose to call the method prototype to be something like 
getAllDerbyKeyWords(String wordToTest) . Hopefully as it has the word 
'Derby' in it the SQL people are unlikely to ever use is in the 
standard! Although maybe there would be an argument to propose a new 
method of getAllKeywords() to the standard, that each driver vendor 
could implement and would have the same / similar functionality - 
delusions of grandeur ;)

But how to turn that String Array into a Table is fairly simple (I'd 
declare a temp table), and then make a select on it to get a resultSet. 
However is there a way to skip the table step and jump straight to a 
result set (its a bit of a leading question, and I haven't searched for 
an answer anywhere yet, so unless you know off the top of your head no 
need to answer straight away).

David

Re: Derby Key Words

[Rick Hillegas <ri...@oracle.com>]

On 9/5/12 7:02 AM, David Myers wrote:
> Hello all,
>
> Bryan, thanks for the info (although I was using 'locate' on my ubuntu
> box, and it still didn't find it ?) I'll have a look tonight.
>
> Kathey, I don't intend to modify the file, just grab the contents, if
> possible an without using a file Input Stream
Hi David,

Note that the keywords appear in an array of String constants that are 
generated by javacc into 
trunk/generated/java/org/apache/derby/impl/sql/compile/SQLParserConstants.java. 
That may be a more straightforward way to get your hands on the keywords 
but it may require understanding more about how the generated grammar 
behaves and it may involve building a compile time tool which scrapes 
the keywords out of SQLParserConstants. I am waving my hands, of course.

Hope this helps,
-Rick
> I also noted that the DatabaseMetaData.getSQLkeywords() actually has a
> hard coded list of words! I have no problem with that in the first
> instance, but I'm sure that the engine doesn' check every word with a
> call to this method before throwing an error!
>
> I need to keep looking...I'll keep you all posted.
>
> D
>
> On Wed, Sep 5, 2012 at 6:25 AM, Katherine Marsden
> <km...@sbcglobal.net>  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
>>
>>

Re: Derby Key Words

[Myrna van Lunteren <m....@gmail.com>]

On Wed, Sep 5, 2012 at 4:02 AM, David Myers
<da...@gmail.com> wrote:
> Hello all,
>
> Bryan, thanks for the info (although I was using 'locate' on my ubuntu
> box, and it still didn't find it ?) I'll have a look tonight.
>
> Kathey, I don't intend to modify the file, just grab the contents, if
> possible an without using a file Input Stream
>
> I also noted that the DatabaseMetaData.getSQLkeywords() actually has a
> hard coded list of words! I have no problem with that in the first
> instance, but I'm sure that the engine doesn' check every word with a
> call to this method before throwing an error!
>
> I need to keep looking...I'll keep you all posted.
>
> D
>
> On Wed, Sep 5, 2012 at 6:25 AM, Katherine Marsden
> <km...@sbcglobal.net> 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
>>
>>

Hi,

In eclipse (using the default shortcut keys), I can find sqlgrammar.jj
when I type the name in the screen that pops up on Ctrl-Shift-R...No
special configuration is needed.

I also wanted to mention, that in some cases, Derby allows SQL 2003
reserved keywords as identifiers for backward compatibility - see for
instance the comments from DERBY-5254
(https://issues.apache.org/jira/browse/DERBY-5254). Other DBMSs may be
more strict...

Myrna

Re: Derby Key Words

[David Myers <da...@gmail.com>]

Hello all,

Bryan, thanks for the info (although I was using 'locate' on my ubuntu
box, and it still didn't find it ?) I'll have a look tonight.

Kathey, I don't intend to modify the file, just grab the contents, if
possible an without using a file Input Stream

I also noted that the DatabaseMetaData.getSQLkeywords() actually has a
hard coded list of words! I have no problem with that in the first
instance, but I'm sure that the engine doesn' check every word with a
call to this method before throwing an error!

I need to keep looking...I'll keep you all posted.

D

On Wed, Sep 5, 2012 at 6:25 AM, Katherine Marsden
<km...@sbcglobal.net> 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
>
>

Re: Derby Key Words

[Katherine Marsden <km...@sbcglobal.net>]

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

Re: Derby Key Words

[Bryan Pendleton <bp...@gmail.com>]

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

thanks,

bryan