calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: avatica jdbc URL connection properties
Date Thu, 01 Oct 2015 14:37:09 GMT
+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 <janvb@ngdata.com> 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 <jhyde@apache.org
> <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 <bruno.dumon@gmail.com
> <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 <bruno.dumon@gmail.com
> <javascript:;>>:
> >>
> >>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <bruno.dumon@gmail.com
> <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
> >>>
> >>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message