ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Fedotov <alexander.fedot...@gmail.com>
Subject Re: New thin JDBC driver
Date Thu, 25 May 2017 07:19:54 GMT
Hi all,

I have a concern regarding 2).
"SQL listener" sounds a bit confusing in scope of IgniteConfiguration since
it doesn't provide a hint on its real purpose.
In Oracle, SQL listener is more like our CommunicationSpi config.

Kind regards,
Alex

25 мая 2017 г. 4:24 AM пользователь "Denis Magda" <dmagda@apache.org>
написал:

> 1) Let's have separate connection string "jdbc:ignite:*thin*://" to avoid
> any confusion and interference with old drivers.

I would use “jdbc:ignite://“ for the newest driver not forcing to use
“thin” in the connection string. I think it’s fine to break the
compatibility there since “jdbc:ignite://“ is used by REST based driver.

—
Denis

> On May 24, 2017, at 5:51 AM, Vladimir Ozerov <vozerov@gridgain.com> wrote:
>
> 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.

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