+1 to what Jan said. Phoenix relies on the connection properties to be passed from client to server. Thanks, James
On Thursday, October 1, 2015, Jan Van Besien <[email protected]> wrote: > 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] > <javascript:;>> 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] > <javascript:;>> 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] > <javascript:;>>: > >> > >>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <[email protected] > <javascript:;>>: > >>> > >>>> 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 > >>> > >>> >
