You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/05/31 18:21:20 UTC
Summary of SQL changes in 2.1
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.
Re: Summary of SQL changes in 2.1
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Sounds good. Can you specify the defaults for the Create Table command?
On Fri, Jun 2, 2017 at 6:55 AM, Vladimir Ozerov <vo...@gridgain.com>
wrote:
> 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 <vo...@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 <ds...@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.
> >> > >
> >> >
> >>
> >
> >
>
Re: Summary of SQL changes in 2.1
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <vo...@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 <se...@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 <ds...@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.
>> > >
>> >
>>
>
>
Re: Summary of SQL changes in 2.1
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <se...@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 <ds...@apache.org>:
>
> > Vladmir,
> >
> > Thanks for the detailed email. My comments are inline...
> >
> > On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <vo...@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.
> > >
> >
>
Re: Summary of SQL changes in 2.1
Posted by Sergi Vladykin <se...@gmail.com>.
I think it makes sense to reserve IGNITE schema for future use as well.
2017-06-01 0:26 GMT+03:00 Dmitriy Setrakyan <ds...@apache.org>:
> Vladmir,
>
> Thanks for the detailed email. My comments are inline...
>
> On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <vo...@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.
> >
>
Re: Summary of SQL changes in 2.1
Posted by Pavel Tupitsyn <pt...@apache.org>.
> 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".
Hi Vladimir,
What is the reason for this limitation?
On Thu, Jun 1, 2017 at 12:26 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> Vladmir,
>
> Thanks for the detailed email. My comments are inline...
>
> On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <vo...@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.
> >
>
Re: Summary of SQL changes in 2.1
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Vladmir,
Thanks for the detailed email. My comments are inline...
On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <vo...@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.
>