Yes -- I would love to find the time/motivation to figure out how to make one :). It's been a while since I've gotten my hands dirty in C/C++. If you (or anyone) wants to do hack on something, I'd be happy to help in whatever way possible.

The stable protocol should be there already (just need some better tests to double check it between releases).

Jesse Yates wrote:
I think it would also be compelling to have an open source ODBC drive
implementation for Avatica. AFAIK there are no 'good', open source
implementations - there are a couple of vendors that sell them (or SDKs to
build them, a dead source-forge project<http://odbcjdbc.sourceforge.net/>,
  or folks roll their own*. I don't imagine it would be to hard, as long as
we keep the Avatica protocol clearly defined.

Something you would be open to @Josh/@Julian?

--Jesse

* would love to be correct here

On Mon, Mar 21, 2016 at 1:18 AM Maxime Jattiot<[email protected]>
wrote:

Hello everyone,

Thank you for all your replies. It clarifies a lot.
I will dig the others Apache projects that use Calcite and will come back
to you if I have further questions.
As suggested by Josh I'll also have a look at who's implementing this
Python Database API.

Thank you again and have a great week !

Maxime



On Fri, Mar 18, 2016 at 8:25 PM Josh Elser<[email protected]>  wrote:

In general, Avatica is just an abstraction of JDBC over an RPC mechanism
via a standalone server. Presently that RPC mechanism is HTTP with
Avatica "protocol" data serialized using JSON or Protocol Buffers.

The general approach I've been trying to follow (agreed upon with Nick a
while back) was to try to keep Avatica horizontally scalable, not
requiring clients to be sticky. Avatica servers do not need to
communicate with each other and should be capable of operating in
parallel with other servers. It is an important caveat that clients
should still try to be sticky (for performance reasons), but it's been a
goal to not make this a requirement. I've done some preliminary testing
with Avatica behind HAProxy with initial success.

Long term, I'd love to provide an array of libraries/drivers for
interfacing with Avatica in the language of your choice. We have the
Java-based implementation (reference implementation) that Avatica
directly provides in the form of a JDBC driver. We've also seen a Python
driver, targeted for Phoenix, that implements the Python Database 2.0
API. ODBC is also a moving target that we can hopefully nail down some
day.
If you have more specific questions WRT architecture/performance, I'd be
happy to try to answer them, Maxime!

- Josh

<snip/>

Josh, Can you weigh in on options for scaling out Avatica?

Julian



On Mar 17, 2016, at 2:32 PM, Maxime Jattiot<[email protected]>
wrote:
<snip/>

- Also you said you are a framework but can you work as an engine that
is queried through ODBC/JDBC ? Is that the purpose of Avatica ? If yes
can
we cluster it to handle many clients queries ?
<snip/>


Reply via email to