calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
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
adapter.

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 <bruno.dumon@gmail.com> 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 <bruno.dumon@gmail.com>:
>
>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <bruno.dumon@gmail.com>:
>>
>>> 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
>>
>>

Mime
View raw message