You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Jan Van Besien <ja...@ngdata.com> on 2015/09/30 13:26:19 UTC
avatica jdbc URL connection properties
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
Re: avatica jdbc URL connection properties
Posted by Josh Elser <jo...@gmail.com>.
Bruno Dumon wrote:
>> > Perhaps move from a single Connection member on JdbcMeta to some factory
>> > that could getOrCreate Connections based on the caller's properties?
>> >
>
> JdbcMeta already manages client-specific connections, the single connection
> is marked for removal:
>
> private final Connection connection; // TODO: remove default connection
> private final Cache<String, Connection> connectionCache;
>
> I did manage to add an OpenConnection rpc request that allows passing
> properties, and it seems to work just fine, though the implementation does
> make one strange jump. I'll looktomorrow to share it via jira.
Oh, well excuse me then. You totally did what I was thinking already.
Sorry for the confusion I made :)
Re: avatica jdbc URL connection properties
Posted by Julian Hyde <jh...@apache.org>.
I'd rather go in the direction of JdbcMeta having as little state as
possible. The principle is that if you ask the same question, you get
the same answer.
The caches necessary to manage connections and statements from the
underlying JDBC data source add a little state, but we should stop
adding state there.
I believe that JdbcMeta should be based off a single connection
specification (url + info). If you want another connection
specification, create another JdbcMeta.
On Thu, Oct 1, 2015 at 12:42 PM, Josh Elser <jo...@gmail.com> wrote:
> Bruno Dumon wrote:
>>>
>>> Maybe JdbcMeta just gets a cache of Drivers tied to a set of properties?
>>> > Reusing ConnectionProperties (via the ConnectionSyncRequest RPC) seems
>>> > to
>>> > make sense to me from a lifecycle sense for now (perhaps ultimately
>>> > moving
>>> > towards encapsulating this state in each RPC to help with the
>>> > statelessness).
>>
>>
>>
>> Hmm, stateless jdbc connections, is that possible? Maybe if it is just for
>> read, but even then it seems challenging.
>>
>
> See https://issues.apache.org/jira/browse/CALCITE-903 for the current
> approach.
Re: avatica jdbc URL connection properties
Posted by Josh Elser <jo...@gmail.com>.
Bruno Dumon wrote:
>> Maybe JdbcMeta just gets a cache of Drivers tied to a set of properties?
>> > Reusing ConnectionProperties (via the ConnectionSyncRequest RPC) seems to
>> > make sense to me from a lifecycle sense for now (perhaps ultimately moving
>> > towards encapsulating this state in each RPC to help with the
>> > statelessness).
>
>
> Hmm, stateless jdbc connections, is that possible? Maybe if it is just for
> read, but even then it seems challenging.
>
See https://issues.apache.org/jira/browse/CALCITE-903 for the current
approach.
Re: avatica jdbc URL connection properties
Posted by Bruno Dumon <br...@gmail.com>.
2015-10-01 19:17 GMT+02:00 Josh Elser <jo...@gmail.com>:
> So, the concrete issue I see presently is that JdbcMeta gets a fixed set
> of Properties (when it's instantiated) and uses those properties to make a
> single Connection for all calls.
>
> Maybe JdbcMeta just gets a cache of Drivers tied to a set of properties?
> Reusing ConnectionProperties (via the ConnectionSyncRequest RPC) seems to
> make sense to me from a lifecycle sense for now (perhaps ultimately moving
> towards encapsulating this state in each RPC to help with the
> statelessness).
Hmm, stateless jdbc connections, is that possible? Maybe if it is just for
read, but even then it seems challenging.
> Perhaps move from a single Connection member on JdbcMeta to some factory
> that could getOrCreate Connections based on the caller's properties?
>
JdbcMeta already manages client-specific connections, the single connection
is marked for removal:
private final Connection connection; // TODO: remove default connection
private final Cache<String, Connection> connectionCache;
I did manage to add an OpenConnection rpc request that allows passing
properties, and it seems to work just fine, though the implementation does
make one strange jump. I'll look tomorrow to share it via jira.
--
Bruno
Re: avatica jdbc URL connection properties
Posted by Josh Elser <jo...@gmail.com>.
So, the concrete issue I see presently is that JdbcMeta gets a fixed set
of Properties (when it's instantiated) and uses those properties to make
a single Connection for all calls.
Maybe JdbcMeta just gets a cache of Drivers tied to a set of properties?
Reusing ConnectionProperties (via the ConnectionSyncRequest RPC) seems
to make sense to me from a lifecycle sense for now (perhaps ultimately
moving towards encapsulating this state in each RPC to help with the
statelessness). Perhaps move from a single Connection member on JdbcMeta
to some factory that could getOrCreate Connections based on the caller's
properties?
I hadn't gotten to actually writing up my own test for the PHOENIX-1824
comment that James had made, but taking Jan's word, this is something
that will have to addressed in some manner for Phoenix :)
James Taylor wrote:
> +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<ja...@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
>>>>>
>>>>>
>
Re: avatica jdbc URL connection properties
Posted by James Taylor <ja...@apache.org>.
+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 <ja...@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
> >>>
> >>>
>
Re: avatica jdbc URL connection properties
Posted by Jan Van Besien <ja...@ngdata.com>.
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 <jh...@apache.org> 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 <br...@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 <br...@gmail.com>:
>>
>>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <br...@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
>>>
>>>
Re: avatica jdbc URL connection properties
Posted by Julian Hyde <jh...@apache.org>.
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 <br...@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 <br...@gmail.com>:
>
>> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <br...@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
>>
>>
Re: avatica jdbc URL connection properties
Posted by Bruno Dumon <br...@gmail.com>.
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 <br...@gmail.com>:
> 2015-09-30 17:23 GMT+02:00 Bruno Dumon <br...@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
>
>
Re: avatica jdbc URL connection properties
Posted by Bruno Dumon <br...@gmail.com>.
2015-09-30 17:23 GMT+02:00 Bruno Dumon <br...@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
Re: avatica jdbc URL connection properties
Posted by Bruno Dumon <br...@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?
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 <ja...@ngdata.com>:
> 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
>
Re: avatica jdbc URL connection properties
Posted by Jan Van Besien <ja...@ngdata.com>.
I think either you misunderstood my question or else I misunderstood
your answer.
I know I can pass properties with an argument to the
DriverManager.getConnection method (or as part of the url as I was
doing). In my use case there are actually 2 jdbc drivers. A "thin"
driver which extends org.apache.calcite.avatica.remote.Driver and a
"real" driver which is our own JDBC driver implemented using calcite.
In between, there is the Avatica RPC.
I pass properties to the "thin" driver (using
DriverManager.getConnection or as part of the URL) but the JdbcMeta on
the server (JdbcMeta.getConnection method) creates a connection with
the "real" driver using the url and properties given to it in my
implementation of the Meta.Factory. I don't see any way to pass the
client side properties to the server via the RPC layer.
Thanks
Jan
On Wed, Sep 30, 2015 at 1:36 PM, Ken Tsay <na...@gmail.com> wrote:
> Checkout DriverManager, Calcite does allows you to set your properties
> object when establish a connection to the server.
> It should be something like this:
>
> DriverManager.getConnection("jdbc:calctie:", properties);
>
> Then you are able to access the attributes in your property object by this:
> Properties props = this.calciteConnection.getProperties();
>
> Hope this help.
>
> Ken
>
>
> On Wed, Sep 30, 2015 at 1:26 PM, Jan Van Besien <ja...@ngdata.com> wrote:
>
>> 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
>>
Re: avatica jdbc URL connection properties
Posted by Ken Tsay <na...@gmail.com>.
Checkout DriverManager, Calcite does allows you to set your properties
object when establish a connection to the server.
It should be something like this:
DriverManager.getConnection("jdbc:calctie:", properties);
Then you are able to access the attributes in your property object by this:
Properties props = this.calciteConnection.getProperties();
Hope this help.
Ken
On Wed, Sep 30, 2015 at 1:26 PM, Jan Van Besien <ja...@ngdata.com> wrote:
> 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
>