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
