You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@quickstep.apache.org by "Robert Claus (JIRA)" <ji...@apache.org> on 2018/01/25 19:24:00 UTC

[jira] [Created] (QUICKSTEP-115) Add Open Network I/O Support

Robert Claus created QUICKSTEP-115:
--------------------------------------

             Summary: Add Open Network I/O Support
                 Key: QUICKSTEP-115
                 URL: https://issues.apache.org/jira/browse/QUICKSTEP-115
             Project: Apache Quickstep
          Issue Type: New Feature
          Components: CLI
            Reporter: Robert Claus


 Quickstep's current network client support is proprietary using GRPC and protobuf.  This isn't particularly difficult to connect to, but does require writing custom support for any language we want to connect from.  It also means no existing 3rd party sql management or testing tools work directly with Quickstep.

Note we won't be able to cover the entire SQL surface regardless of the solution developed due to ongoing work in other sections of the code, but this would offer a clean way of connecting to external systems for testing and demonstrating Quickstep.

After exploring some options, I recommend we add support for Postgres's protocol for connecting to network clients.  This will allow Quickstep to start up, and any client that can connect to Postgres will be able to connect to Quickstep in its place.  This protocol is well documented and since Postgres is open source it should be easy to find answers to implementation questions.  Note while this is proprietary to Postgres, adapters already exist for ODBC and it is already directly supported by most languages.

[https://www.postgresql.org/docs/9.3/static/protocol.html]

Other options considered:

Avatica ([http://calcite.apache.org/avatica/]) - The current project is focused on JDBC support and has not been robustly implemented.  While it would probably be easier to implement, I believe the bang-for-your-buck is lower.

Quickstep ODBC Driver - This would be a nice catch-all solution for most use cases since adapter solutions from ODBC to other protocols exist for most systems.  However, directly implementing an ODBC driver is high effort.  Additionally, installing the adapters to use ODBC is not always trivial.

Implementations Per Use Case - A separate library for every supported language, and no support for third party tools unless those tools add support for Quickstep.  This is the lowest immediate effort (python and node.js libraries already exists in a fork) but will be the highest effort long term and the hardest to maintain and coordinate.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)