Folks, Let me summarize all recent changes to our SQL engine which are important from user perspective. Please think of them and let me know if you have any objection and thoughts on how to improve them.
1) Default "PUBLIC" schema added. It always exists and cannot be dropped. Many caches can reside in this schema as opposed to earlier versions, where every cache must be in separate schema. 2) Caches are still created in separate schemas by default. We should not change this behavior, because it could break SQL queries of virtually all users. 3) "CREATE TABLE" creates a cache with special internal property "sql=true". Such cache cannot be destroyed through "Ignite.destroyCache". It can only be dropped through "DROP TABLE".The opposite is also holds: static and dynamic caches cannot be dropped through "DROP TABLE". 4) "CREATE INDEX" and "DROP INDEX" can only be executed on "sql" caches. 5) There will be two predefined templates for "CREATE CACHE" command - "REPLICATED" and "PARTITIONED". They are always available on any node. 6) Additional parameters which could be passed to "CREATE TABLE": 6.1) "cacheTemplate" - name of cache template 6.2) "backups" - number of backups 6.3) "atomicityMode" - either "TRANSACTIONAL" or "ATOMIC" 6.4) "AFFINITY KEY" - if key field should be used for affinity. Example: CREATE TABLE Employee ( pk_id BIGINT PRIMARY KEY, name VARCHAR(255), org_id BIGINT AFFINITY KEY ) WITH "cacheTemplate=PARTITIONED, backups=1, atomicityMode=TRANSACTIONAL" 7) Connetion string of new JDBC driver starts with "jdbc:ignite:thin://", and has only [host] as mandatory parameter. Example: "jdbc:ignite:thin://my_machine" 8) New bean "SqlConfiguration" will be added to "IgniteConfiguration": class SqlConfiguration { SqlListenerConfiguration listenerCfg; // Content of this class will be copied from OdbcConfiguration; long longQryWarnTimeout; // Moved from CacheConfiguration // Will hold more common SQL stuff such as metrics frequency, predefined schemas, etc. in future. } class SqlListenerConfiguration { String host; // Optional, bind to all interfaces if ommitted; int port; // Port // Other stuff copied from OdbcConfiguration } Example of configuration with explicitly enabled listener: new IgniteConfiguration().setSqlConfiguration(new SqlConfiguration().setListenerConfiuration(new SqlListenerConfiguration())); 9) SQL listener *will not be enabled by default* as it consumes resources and normally will be require only on small set of nodes. 10) OdbcConfiguration will be deprecated in favor of SqlListenerConfiguration. Please share your thoughts.