db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenton Garner <kenton.gar...@issinc.com>
Subject RE: issues.apache.org/jira/browse/DERBY-3946
Date Thu, 16 Oct 2014 20:17:34 GMT
Rick, sorry it took me so long to respond.

I was just starting to look at this preferred way when I noticed that you have included the
line
"create table t( a int );"   In your sample instructions.

Does this imply that it will need to bind all of the SQL statements to a current data dictionary
in order for it to parse the SQL?

Unfortunately, I will not have tables associated with the SQL I parse.  
That was one of the advantages of the previous method - it was not required.  It stopped immediately
after parsing and did not require a valid data dictionary.

-Kent

-----Original Message-----
From: Rick Hillegas [mailto:rick.hillegas@oracle.com] 
Sent: Tuesday, October 14, 2014 8:41 AM
To: Kenton Garner; Derby Discussion
Subject: Re: issues.apache.org/jira/browse/DERBY-3946

Hi Kent,

I'm moving this discussion to the derby-user@db.apache.org mailing list 
so that it will be archived in case anyone else is interested later on.

The work on DERBY-3946 was superseded by the work on DERBY-4415. I've 
resolved DERBY-3946. Hopefully that will help point people at DERBY-4415 
so that they don't spend too much time wrestling with the old approach. 
The solution on DERBY-4415 works with production (non-debug) engines. I 
have just verified that it still works with the latest 10.11.1.1 release.

What I recommend is this: Write your own custom version of 
XmlASTPrinter. Then follow DERBY-4415's instructions for printing an 
xml-formatted tree:

connect 'jdbc:derby:memory:dummy;create=true';

create table t( a int );

call syscs_util.syscs_register_tool( 'customTool', true, 'ASTInspector', 
'XmlASTPrinter' );

select * from t;

call syscs_util.syscs_register_tool( 'customTool', false, 'ASTInspector' );

- now look for the output in derbyAST.xml

Feel free to ask more questions or make more suggestions, either on this 
email thread or on DERBY-4415.

Hope this helps,
-Rick

On 10/13/14 3:36 PM, Kenton Garner wrote:
>
> Rick,
>
> I have been looking for a SQL Parser for a while now with no success ( 
> various ANTLR/ JAVACC examples came close - but no joy ).
>
> Today I came across a discussion about the support you added to Derby 
> to allow it to be used to generate Abstract Syntax Trees. This is great!
>
> I have to be able to take SQL statements parsed from a log for basic 
> DML ( INSERT, UPDATE, DELETE ) and be able to convert the SQL to a 
> custom XML format and potentially re-apply the SQL programmatically to 
> another database.
>
> I know your work for this was done a while ago, but I would love to 
> make use of it. This is what I have done so far.
>
> 1.Download the debug version of the Derby libs from db.apache.org 
> (Derby distributed with Java 7 JDK does not work here).
>
> 2.Update your sample ASTParser.java and TreeWalker.java to use the 
> "org.apache.derby.shared.common.sanity.SanityManager".
>
> 3.Read your discussions on the Derby jira page in regards to the 
> TreeWalker/Visitor and class relationships.
>
> 4.Ran some tests with basic INSERT SQL Statement.
>
> It appears that since this is using an in memory database that I do 
> not have to have a data dictionary or other details pre-existing in 
> the database for the basic SQL Parsing to work. - Great News!
>
> Note: I would be glad to ask my questions in another forum if you 
> prefer, but I do not know how to add questions to the Derby jira page.
>
> My question is basically...
>
> Since both the ASTParser and the TreeWalker make use of package level 
> calls that I have no access to; And knowing the node class from the 
> TreeWalker does not provide me any greater access to the information 
> that I need. How would you recommend I make best use of this code?
>
> My first though was that I would have to modify the Derby code to get 
> access to package, protected and private methods/variables - but I 
> would obviously rather not alter the Derby code. Do you have any 
> suggestions? Perhaps I am missing the obvious.
>
> Thank you so much.
>
> -Kent
>


Mime
View raw message