[
https://issues.apache.org/jira/browse/CALCITE-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458206#comment-16458206
]
Sasha Ovsankin edited comment on CALCITE-2280 at 4/29/18 9:34 PM:
------------------------------------------------------------------
Very rough draft, just off the top of my head (in Thrift-like format, LMK if a
different format is preferred). Will consult with Heli tomorrow for possible
update:
{code:java}
enum LevelOfDetail {
TABLE,
COLUMN,
FIELD
}
struct Input {
string table;
optional string column; // not needed if DetailLevel.TABLE was requested
optional string field; // for complex types
}
struct Output {
string table;
optional string column;
optional string subfield;
list<i32> inputs; // ids of inputs that contributed to this field
}
struct LineageResult {
// IDs -> input record. Alternative is a list of records with IDs
optional map<i32, Input> inputs;
optional list<Output> outputs;
}
service Lineage {
// return a graph of connections between inputs and outputs
LineageResult lineage(string statement, LevelOfDetail level);
}
{code}
was (Author: sashao):
Very rough draft, just off the top of my head (in Thrift-like format, LMK if a
different format is preferred). Will consult with Heli tomorrow for possible
update:
{code:java}
enum LevelOfDetail {
TABLE,
COLUMN,
FIELD
}
struct Input {
string table;
optional string column; // not needed if DetailLevel.TABLE was requested
optional string field; // for complex types
}
struct Output {
string table;
optional string column;
optional string subfield;
list<i32> inputs; // ids of inputs that contributed to this field
}
struct LineageResult {
// IDs -> input record. Alternative is a list of records with IDs
optional map<i32, Input> inputs;
optional list<Output> outputs;
}
service Lineage {
LineageResult lineage(string statement, LevelOfDetail level);
}
{code}
> "Super-liberal" parser that accepts all SQL dialects
> ----------------------------------------------------
>
> Key: CALCITE-2280
> URL: https://issues.apache.org/jira/browse/CALCITE-2280
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
>
> Create a parser that accepts all SQL dialects.
> It would accept common dialects such as Oracle, MySQL, PostgreSQL, BigQuery.
> If you have preferred dialects, please let us know in the comments section.
> (If you're willing to work on a particular dialect, even better!)
> We would do this in a new module, inheriting and extending the parser in the
> same way that the DDL parser in the "server" module does.
> This would be a messy and difficult project, because we would have to comply
> with the rules of each parser (and its set of built-in functions) rather than
> writing the rules as we would like them to be. That's why I would keep it out
> of the core parser. But it would also have large benefits.
> This would be new territory Calcite: as a tool for manipulating/understanding
> SQL, not (necessarily) for relational algebra or execution.
> Some possible uses:
> * analyze query lineage (what tables and columns are used in a query);
> * translate from one SQL dialect to another (using the JDBC adapter to
> generate SQL in the target dialect);
> * a "deep" compatibility mode (much more comprehensive than the current
> compatibility mode) where Calcite could pretend to be, say, Oracle;
> * SQL parser as a service: a REST call gives a SQL query, and returns a JSON
> or XML document with the parse tree.
> If you can think of interesting uses, please discuss in the comments.
> There are similarities with Uber's
> [QueryParser|https://eng.uber.com/queryparser/] tool. Maybe we can
> collaborate, or make use of their test cases.
> We will need a lot of sample queries. If you are able to contribute sample
> queries for particular dialects, please discuss in the comments section. It
> would be good if the sample queries are based on a familiar schema (e.g.
> scott or foodmart) but we can be flexible about this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
