ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: New thin JDBC driver
Date Wed, 24 May 2017 18:51:34 GMT

In general, all good ideas. However, I am concerned about having SQL
embedded into the server side configuration. I think we need to combine
JDBC, ODBC, REST, and Thin Client into the same approach and have the same
configuration for all of them.

What do you think?


On Wed, May 24, 2017 at 5:51 AM, Vladimir Ozerov <vozerov@gridgain.com>

> Igniters,
> Currently we have two JDBC drivers:
> v1 - old thin driver, deprecated, works over GridClient
> v2 - fat driver, works over Ignite started in "client" mode.
> Both of them have the same connection string "jdbc:ignite://"
> Now we are working on new thin driver. It will use almost the same protocol
> as current ODBC driver, and will require only single port to be opened.
> Also this driver will not be coupled to particular cache. Now I am thinking
> on how to expose it to through public API. My considerations:
> 1) Let's have separate connection string "jdbc:ignite:*thin*://" to avoid
> any confusion and interference with old drivers.
> 2) Let's rename (actually deprecate + duplicate) OdbcConfiguration to
> SqlListenerConfiguration. This is where users will define port and other
> server-side parameters. It will be configurable through
> IgniteConfiguration.sqlListenerConfiguration.
> I think "listener" is a good term here, as it is also used in conventional
> RDBMS, such as Oracle.
> 3) We need to decide whether to start listener service by default or not.
> Tough question. On the one hand, it is convenient if any Ignite node will
> be able to serve SQL requests with no additional configuration. On the
> other hand, it consumes resources and threads (GridNioServer), and normally
> users will have limited set of nodes which will serve user requests. For
> this reason I would not start it by default in the first place.
> Please share your thoughts, especially about p.2 since I am in great doubts
> about it.
> Vladimir.

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