New thin JDBC driver

[Vladimir Ozerov]

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.

[dsetrakyan]

Vladimir,

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?

D.

On Wed, May 24, 2017 at 5:51 AM, Vladimir Ozerov <[hidden email]>
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.
>

[dmagda]

> 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 <[hidden email]> 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.

[afedotov]

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" <[hidden email]>
написал:

> 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 <[hidden email]> 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.

[Vladimir Ozerov]

I think I will add completely *new *top-level bean "SqlConfiguration". For
now it will contain:

1) Long query warning timeout (it doesn't make sense anymore on cache
configuration)
2) SQL function classes (also move from cache config)
3) Listener parameters: host, port, max cursors

On Thu, May 25, 2017 at 10:19 AM, Alexander Fedotov <
[hidden email]> wrote:

> 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" <[hidden email]>
> написал:
>
> > 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 <[hidden email]>
> 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.
>