Re: New thin JDBC driver
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 < alexander.fedot...@gmail.com> 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"> написал: > > > 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 > 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. >
Re: New thin JDBC driver
> 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 Ozerovwrote: > > 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.
Re: New thin JDBC driver
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 Ozerovwrote: > 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. >
New thin JDBC driver
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.