Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CA+eZwrH43LV5A=buF3ABnuNj7=0=oFeXgqvuBaaCsaaDPJvGsA@mail.gmail.com>
References: <CAGt6o8kmK7stkkyJ40Ot-Y80Sp58tAc5qEGy54g-CtJ0ZV1ARA@mail.gmail.com>
 <CA+0=VoX22z_Go98zsTk2je1Yjhf_U7RtPXQnMHrvudqiT8+Sxw@mail.gmail.com> <CA+eZwrH43LV5A=buF3ABnuNj7=0=oFeXgqvuBaaCsaaDPJvGsA@mail.gmail.com>
From: Vladimir Ozerov <vozerov@gridgain.com>
Date: Thu, 1 Jun 2017 12:35:51 +0300
Message-ID: <CAGt6o8mz-SzCOA91wqoR2aFy_E-hfenR2eSwVK0DrRfMnCaZ+A@mail.gmail.com>
Subject: Re: Summary of SQL changes in 2.1
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="f403045f8b563cb6de0550e2c371"
archived-at: Thu, 01 Jun 2017 09:36:05 -0000

--f403045f8b563cb6de0550e2c371
Content-Type: text/plain; charset="UTF-8"

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.
> > >
> >
>

--f403045f8b563cb6de0550e2c371--