db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: Using derby to parse an SQL statement
Date Wed, 12 Nov 2008 15:13:59 GMT
Hi Christian,

I think you will have difficulty isolating the Parser from the rest of 
the SQL interpreter. In theory, you should be able to isolate the 
compiler from the execution engine and the storage layer--but that is an 
untested theory.

The Parser wants to turn out abstract syntax trees (AST). Ideally, the 
Parser would just need to ask a NodeFactory for AST nodes and you could 
supply your own NodeFactory. But I think that there is a fair amount of 
coupling between the Parser and Derby's concrete implementation of 
NodeFactory. I think that you could uncouple the two, but you may not 
want to spend your time on that.

So the Parser is going to force you to pull in the AST nodes. Once you 
do that, you will end up with the whole compiler. In particular, the AST 
nodes (and the Parser itself) expect that you will supply an 
implementation of LanguageConnectionContext, the master state variable 
for the whole SQL interpreter. Untangling that requirement is another 
chunk of work you may not want to do.

Then there is the Monitor. It has been a while since I was in that code 
but I seem to recall that fairly early on the Monitor wants to fault in 
a storage layer. In theory you ought to be able to supply the Monitor a 
list of modules that doesn't include a storage layer. But since no-one 
runs in this configuration, there are probably a lot of undocumented 
surprises that you may not want to fix either.

Can I ask you what breaks if you just pull in the whole Derby engine? 
Are you concerned that you will fault in too much code that you barely 
use? Are you concerned that you'll end up with a dummy database that you 
don't need? Are Derby's AST nodes not a usable representation of 
statement syntax?

Thanks,
-Rick

Christian Riedel wrote:
> Hi there,
>
> we are working on a small project where we need to analyze an SQL 
> statement that can be of any kind: very simple, with inner selects, 
> complex join etc.
>
> We figured it inappropriate to start to write our own parser when 
> there are other projects, like derby, out there that can do it much 
> better than we would possibly do ... so this was our idea:
>
> Can we use derby to create an instance of Parser 
> (org.apache.derby.iapi.sql.compile.Parser.class) and let our SQL 
> statement be parsed by calling the parse() method on this instance? 
> What we want to have is a syntax tree of the statement that allows us 
> to see which tables and which fields are accessed / included in the 
> statement (including any possibly done "renames" รก la SELECT street AS 
> "ADDRESS" FROM USER_DATA ).
>
> The problem is, that we are stuck ... we spent several days now to try 
> to find the proper way to create an instance of the Parser. Is it 
> possible at all without having to set up a running derby system?
>
> Is the Monitor class the right entry point? How can we create a 
> CompilerContext so that a Parser instance can be created?
>
>
> This sure is off-topic but we don't see any way through all this. Can 
> you help us?
>
>
> Thanks in advance
>
> Christian
>


Mime
View raw message