The latter. The core of Calcite is the relational algebra, and the planning rules, and the planner. I usually describe SQL and JDBC as optional; in https://www.slideshare.net/julianhyde/a-smarter-pig-building-a-sql-interface-to-apache-pig-using-apache-calcite <https://www.slideshare.net/julianhyde/a-smarter-pig-building-a-sql-interface-to-apache-pig-using-apache-calcite> we described it as “not-just-SQL”.
Our positioning may seem a little schizophrenic. We sometimes claim to be a framework, other times claim to be a full SQL system (albeit not very performant/scalable). I think it’s OK; being able to demo SQL gives people confidence to use Calcite as a framework. I would love to have a SPARQL front-end (actually I gather one of our contributors has written a SPARQL front-end). The piglet module is a front-end that is a subset of Pig latin. Then there’s the linq4j module (if you would like to write in a Spark-like language). And ReBuilder if you want an easier way of building algebra. Lastly, Hive uses its own SQL parser (with its own SQL extensions) but still uses Calcite for planning. Julian > On Oct 30, 2017, at 9:40 PM, Edmon Begoli <[email protected]> wrote: > > A question about the nature of Calcite architecture: > > is Calcite envisioned as solely a relational query processor -- in > other words having a SQL interface to other sources -- or does it > happen to be that SQL query processor is by far the most mature, but > it is just one of many; i.e. tomorrow we might want to support SPARQL, > etc. as equally as SQL?
