Regarding other comments:
1) Config - agree, let's have a single flat class "SqlServerConfiguration"
to store listener config. It will be a replacement for OdbcConfiguration.
2) Ok, let's allow users to create indexes on non-SQL caches. This may be
convenient in some cases.

On Thu, Jun 1, 2017 at 12:35 PM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Dmitry, Pavel, regarding limitations:
>
> 1) Caches created through SQL should not interfere with caches created
> through API and config. We do not understand all implications of this
> interference for now, especially in the context of persistence, so it is
> better to restrict this behavior for now. Especially provided that in most
> situations this restricted case doesn't make sense.
>
> 2) CREATE INDEX on non-sql caches doesn't make sense. Yes, we implemented
> this in 2.0, but in this versions users have to define table structure
> through QueryTable before cache start, and cannot change it in future. As
> such, in 2.0 any "CREATE INDEX" could be replaced with proper QueryEntity
> configuration on cache start. That is, "CREATE INDEX" is effectively
> useless in 2.0.
>
> On Thu, Jun 1, 2017 at 12:17 PM, Sergi Vladykin <sergi.vladykin@gmail.com>
> wrote:
>
>> I think it makes sense to reserve IGNITE schema for future use as well.
>>
>> 2017-06-01 0:26 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>>
>> > Vladmir,
>> >
>> > Thanks for the detailed email. My comments are inline...
>> >
>> > On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <vozerov@gridgain.com
>> >
>> > wrote:
>> >
>> > > 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.
>> > >
>> >
>> > Nice!
>> >
>> >
>> > > 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.
>> > >
>> >
>> > We should document, however, that this behavior will change in 3.0.
>> Also,
>> > users should be able to specify that they wish to connect to the PUBLIC
>> > schema explicitly.
>> >
>> >
>> > > 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".
>> > >
>> >
>> > Agree.
>> >
>> >
>> > >
>> > > 4) "CREATE INDEX" and "DROP INDEX" can only be executed on "sql"
>> caches.
>> > >
>> >
>> > Ouch! Many of current Ignite users wish to have this functionality
>> enabled
>> > for API-based caches. Any chance to lift this limitation?
>> >
>> >
>> > >
>> > > 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.
>> > >
>> >
>> > What are the defaults?
>> >
>> >
>> > >
>> > > 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"
>> > >
>> >
>> > Why not have "thin" driver by default? Will users even notice?
>> >
>> >
>> > >
>> > > 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()));
>> > >
>> >
>> > Seems that there is one-to-one dependency between SqlConfiguration and
>> > SqlListenerConfiguration. This looks a bit dirty. Why not just have
>> > SqlConfiguration with all the properties?
>> >
>> >
>> > >
>> > > 9) SQL listener *will not be enabled by default* as it consumes
>> resources
>> > > and normally will be require only on small set of nodes.
>> > >
>> >
>> > Again, seems to be very odd. I would like SqlConfiguration to be
>> enabled by
>> > default, given that many users will now connect to Ignite using the
>> JDBC or
>> > ODBC drivers.
>> >
>> >
>> > >
>> > > 10) OdbcConfiguration will be deprecated in favor of
>> > > SqlListenerConfiguration.
>> > >
>> >
>> > Again, let's just have one SqlConfiguration interface. I am OK with
>> > deprecating the OdbcConfiguration, assuming that it will still work.
>> >
>> >
>> >
>> > >
>> > > Please share your thoughts.
>> > >
>> >
>>
>
>