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? Related, the username/password are also connection-creation-time parameters. Is there any preference in how to approach that? I see two options: (1) username/password are passed to the server once at connection creation time, probably just as part of the connection properties (2) authentication happens in a separate rpc call, which responds with an authentication token which is passed on each request The 'authentication token' of option (2) is very similar to the connection id (which is a UUID), so I guess option (1) is good enough. -- Bruno 2015-09-30 13:26 GMT+02:00 Jan Van Besien <[email protected]>: > Hi, > > I have an avatica (remote RPC) implementation to create a "thin" jdbc > client for our > existing "thick" jdbc client implemented with calcite. > > I was wondering if there is a way to pass connection properties from > the client JDBC connection URL to the server. > > In other words, my client JDBC url would be something like > > jdbc:xyz:thin:url=http://localhost:8765;key=value > > And I want to know server side that the property "key" has value > "value", ideally before making the actual server side JDBC connection > for requests from this client. > > For a moment I thought ConnectionSyncRequest is what I need, but that > seems to define a fixed set of properties. > > Does this make sense? > > > Thanks > Jan >
