I see. You intend to generate SQL. So this would be a dialect for the JDBC adapter.
On Thu, Jan 9, 2020 at 10:50 PM Forward Xu <[email protected]> wrote: > > Hi Julian, > > In addition, we can also implement a PrestoSqlDialect. > > > Best, > > Forward > > Forward Xu <[email protected]> 于2020年1月10日周五 下午2:23写道： > > > Hi Julian, > > > > The current idea is through com.facebook.presto.spi. > > 1. Can be achieved through plugs provided by presto. For example [1]. > > 2. You can construct Connector directly through > > com.facebook.presto.spi.ConnectorFactory [2]. > > > > Best, > > Forward > > > > [1] > > https://www.codota.com/code/java/methods/com.facebook.presto.spi.Plugin/getConnectorFactories > > [2] > > https://www.programcreek.com/java-api-examples/?code=y-lan/presto/presto-master/presto-raptor/src/main/java/com/facebook/presto/raptor/RaptorPlugin.java > > > > Julian Hyde <[email protected]> 于2020年1月10日周五 上午2:03写道： > > > >> Sounds like you are planning to target Presto’s internal engine rather > >> than Presto the database. To clarify, can you give an example of the code > >> that you would generate and send to Presto for a simple SQL query? > >> > >> Julian > >> > >> > >> > On Jan 9, 2020, at 5:07 AM, Forward Xu <[email protected]> wrote: > >> > > >> > Hi, Stamatis > >> > > >> > Because we have a number of internal clusters already using and > >> installing > >> > presto. And we want use calcite to optimize the parser and push it down > >> to > >> > presto, spark and other calculation engines or olaps. Utilize the sql > >> > optimization function of calite in combination with distributed > >> computing > >> > engines or distributed olaps such as presto. In this way, each > >> performance > >> > can be exerted. > >> > > >> > Best, > >> > Forward > >> > > >> > Stamatis Zampetakis <[email protected]> 于2020年1月9日周四 下午8:51写道： > >> > > >> >> Hi, > >> >> > >> >> Presto seems to have many similarities with Calcite itself. > >> >> As you mentioned, Presto is not really a database but a distributed SQL > >> >> framework to query heterogeneous data sources. > >> >> Presto connectors are in some sense similar to Calcite adapters and if > >> the > >> >> Enumerable convention was capable of performing distributed joins etc., > >> >> then the similarities would be even bigger. > >> >> > >> >> To the best of my knowledge, the majority of our users adopt Calcite > >> either > >> >> to query multiple data sources in a unified way or to provide SQL query > >> >> processing capabilities to data sources that do not already have. > >> Presto > >> >> seems to have similar goals, thus, I am not sure who will benefit from > >> this > >> >> new adapter. > >> >> > >> >> I never used Presto myself so I may have missed some important points. > >> Can > >> >> you share some use-cases about who may use this adapter and how? > >> >> > >> >> Best, > >> >> Stamatis > >> >> > >> >> > >> >> On Wed, Jan 8, 2020 at 2:44 PM Forward Xu <[email protected]> > >> wrote: > >> >> > >> >>> Hi everybody, > >> >>> > >> >>> I'd like to kick off a discussion on Implement Presto adapter in > >> calcite. > >> >>> > >> >>> We know that presto is also a powerful SQL query tool, which is widely > >> >> used > >> >>> with the olap of big data. So I want to add an adapter for presto to > >> >>> calite. > >> >>> > >> >>> Would love to hear your thoughts. > >> >>> > >> >>> Best, > >> >>> Forward > >> >>> > >> >> > >> > >>
