Eclipse Community Forums: DTP » Generic parser API

Help

Home

Home » Eclipse Projects » DTP » Generic parser API

Show: Today's Messages :: Show Polls :: Message Navigator

Generic parser API [message #517495]

Sun, 28 February 2010 18:54

Slavik Taubkin

Messages: 4
Registered: February 2010

Junior Member

I just figured out that DTP uses two different kinds of SQL parsers: JavaCC and LPG based.

I have the following problem: I only have a database specific extended JavaCC-parser (extension of org.eclipse.datatools.sqltools.sql.parser.SQLParser). And my aim is to analyze a SQL query in order to print out all columns used in this query. I would easily solve this task using SQL query model, but JavaCC-parser doesn't support this...

I found the following statements in a mail thread from the Eclipse project: "a common parser API (for callers to work with any parser) is planned in the next release of DTP (post DTP 0.9)..." and "...The generic sql parser API will help us to achieve this goal. DTP will only interact with the parser using the generic parser API, no matter what the underlying parser it is".

These mails were written on the June 1, 2006. Now DTP 1.7 is there. Is generic parser API already implemented? Or is there any chance to use the existing AST (parsing tree) from JavaCC-based parser for the recognition of QueryStatement?

Report message to a moderator

Re: Generic parser API [message #525857 is a reply to message #517495]

Thu, 08 April 2010 01:46

Brian Payton

Messages: 154
Registered: July 2009

Senior Member

Unfortunately the common parser API was never implemented.

What database type are you using? Are you analyzing SQL Select
statements only? If so, and your SQL dialect is not too non-standard,
you might be able to use the SQL Query parser and model to do the analysis.

Slavik Taubkin wrote:
> I just figured out that DTP uses two different kinds of SQL parsers:
> JavaCC and LPG based.
>
> I have the following problem: I only have a database specific extended
> JavaCC-parser (extension of
> org.eclipse.datatools.sqltools.sql.parser.SQLParser). And my aim is to
> analyze a SQL query in order to print out all columns used in this
> query. I would easily solve this task using SQL query model, but
> JavaCC-parser doesn't support this...
>
> I found the following statements in a mail thread from the Eclipse
> project: "a common parser API (for callers to work with any parser) is
> planned in the next release of DTP (post DTP 0.9)..." and "...The
> generic sql parser API will help us to achieve this goal. DTP will only
> interact with the parser using the generic parser API, no matter what
> the underlying parser it is".
>
> These mails were written on the June 1, 2006. Now DTP 1.7 is there. Is
> generic parser API already implemented? Or is there any chance to use
> the existing AST (parsing tree) from JavaCC-based parser for the
> recognition of QueryStatement?

Report message to a moderator

Re: Generic parser API [message #525947 is a reply to message #525857]

Thu, 08 April 2010 11:23

Slavik Taubkin

Messages: 4
Registered: February 2010

Junior Member

Thank you for the reply!
I have to analyse different kinds of statements (including DELETEs, UPDATEs, INSERTs). I "solved" this problem by splitting the original statement into smaller pieces that can be parsed with the generic parser.

Regards,
Slavik

Report message to a moderator

Re: Generic parser API [message #526153 is a reply to message #525947]

Fri, 09 April 2010 00:38

Brian Payton

Messages: 154
Registered: July 2009

Senior Member

OK, glad you have it working. When you say the generic parser, which
parser do you mean?

BTW, the SQLQueryParser (the LPG-based one) is designed to parse SELECT,
INSERT, UPDATE, DELETE, and MERGE statements. And the classes in the
"helper" package in org.eclipse.modelbase.sql.query plugin are designed
to get information from a generated query model such as all the column
references in a statement.

Slavik Taubkin wrote:
> Thank you for the reply!
> I have to analyse different kinds of statements (including DELETEs,
> UPDATEs, INSERTs). I "solved" this problem by splitting the original
> statement into smaller pieces that can be parsed with the generic parser.
>
> Regards,
> Slavik

Report message to a moderator