Sounds good. Can you specify the defaults for the Create Table command?
On Fri, Jun 2, 2017 at 6:55 AM, Vladimir Ozerov <voze...@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 <voze...@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.vlady...@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 <dsetrak...@apache.org>:
> >>
> >> > Vladmir,
> >> >
> >> > Thanks for the detailed email. My comments are inline...
> >> >
> >> > On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov <
> voze...@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.
> >> > >
> >> >
> >>
> >
> >
>
