Julian, I don't think Bruno's idea was to pass client connection properties into the schema, but into the server-side connection (managed by JdbcMeta). But before potentially drowning ourselves in details of the implementation, maybe we should discuss whether the use case itself makes sense (for avatica) first.
Our use case is to provide a thin-client variant of our existing JDBC driver which behaves exactly the same as the existing "thick" jdbc driver. The behavior of the existing driver currently depends on a number of properties that can be set via the Properties instance passed through the DriverManager.getConnection(url, props). We would like users of the thin driver to be able to do this as well. Furthermore, we would like to integrate a form of authentication in the thin-client such that the client side credentials are used to authenticate server side. I think this corresponds to what is described in CALCITE-643. If we don't pass client side properties to the server, and if we don't have a one-to-one mapping of client side connections to server side connections, I don't see how this use case is possible. Our use case is actually very (if not completely) similar to what apache-phoenix is doing with their query server [1]. They also use connection properties (TenantId, CurrentSCN, ...) to influence the behavior of the driver, and they suffer from the same problem (i.e. these properties simply don't work through their QueryServer). I started a discussion on the phoenix dev mailing list to see what their ideas on this topic are, but at least some comments in PHOENIX-1824 [2] seem to suggest that they assume this should transparently work in Avatica. Thanks, Jan [1] https://phoenix.apache.org/server.html [2] https://issues.apache.org/jira/browse/PHOENIX-1824?focusedCommentId=14746605&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14746605 On Wed, Sep 30, 2015 at 6:35 PM, Julian Hyde <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]>: >> >>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <[email protected]>: >>> >>>> 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 >>> >>>
