calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: avatica jdbc URL connection properties
Date Wed, 30 Sep 2015 16:35:05 GMT
A calcite schema is designed to be shared among multiple connections.
It might be created before the first connection (not currently, but
you could imagine a "Calcite server") and out-live all connections.
And it might be in use simultaneously by two connections: Fred and Bob
are both accessing Calcite and reading the EMP table via the CSV

In that light, it doesn't make sense to pass the client's connection
properties (e.g. username = Bob) into the schema.

If we were to change schemas to what you are proposing, we would lose
a lot. E.g. the ability to cache.

On Wed, Sep 30, 2015 at 8:48 AM, Bruno Dumon <> wrote:
> It does seem a bit strange that there are Meta implementations which wrap a
> single connection, while at the same time some Meta methods
> (createStatement) take a ConnectionHandle as parameter.
> 2015-09-30 17:41 GMT+02:00 Bruno Dumon <>:
>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <>:
>>> Hi,
>>> I am looking into the same thing, and I think we need a "create
>>> connection" operation in the avatica rpc, since these properties are passed
>>> at connection creation time. Right now connections are implicitly created
>>> when the client passes an unknown connection id.
>>> On first sight the most logical place to do this is by adding a connect()
>>> method implementation to remote.Driver that performs the rpc to create the
>>> connection on the server. This would assume we have at that point access to
>>> Service.Factory, but that is not the case, as this is created by the
>>> Connection itself by calling Driver.createMeta(). Another issue is that it
>>> is the AvaticaConnection constructor which decides on the connection id. A
>>> solution might be to refactor this so that these things are created by the
>>> driver and passed to the connection constructor (via
>>> AvaticaFactory.newConnection), does this sound reasonable?
>> I overlooked the fact that some Meta implementations wrap the connection,
>> so it is not easily possible to reverse this.
>> Ideas on how to approach adding a "create connection" rpc call definitely
>> welcome :-)
>> --
>> Bruno

View raw message