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