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+0=VoWcJXiJo4eMnDBcO4DJaxpVqEbC1hWovV1V4JNdAyWRKg@mail.gmail.com>
References: <CAJhSPboO_qEjtbEBZdb1hA_yCHFbEqzDX5wNVVqtf1nF0GZ_BA@mail.gmail.com>
 <CALH+G9rAbKnmBX9f7tE2qh5OxgJPz2XJYy9gsaz_eD=k63Lg4Q@mail.gmail.com>
 <CAGt6o8kgLpYf=JvOUrJRTYQGNCkmngtHRkNNVDeiPoQqz2X6RA@mail.gmail.com>
 <CAMbfdjaN7HuNE0FHK8CuwD+0i+h9X4GEEYNe3SaPOFrgsDgj1Q@mail.gmail.com> <CA+0=VoWcJXiJo4eMnDBcO4DJaxpVqEbC1hWovV1V4JNdAyWRKg@mail.gmail.com>
From: Sergey Kozlov <skozlov@gridgain.com>
Date: Thu, 12 Jan 2017 11:41:01 +0300
Message-ID: <CAMbfdjZMMZ06TbZP3QtBuUAFet8rN4hLQ1t1gi2iLDBTStO9+Q@mail.gmail.com>
Subject: Re: DDL implementation details
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c1b4e9a635db80545e1adb8
archived-at: Thu, 12 Jan 2017 08:41:14 -0000

--94eb2c1b4e9a635db80545e1adb8
Content-Type: text/plain; charset=UTF-8

As first stage of DDL we can implement following CREATE TABLE statement
support:
 - CREATE TABLE without cache properties (use default cache properties or
cache properties defined in SQL Schema)
 - CREATE TABLE .. LIKE where we can create a cache based on an another
existing cache.

On Thu, Jan 12, 2017 at 5:54 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> Agree with Sergey. We should be able to specify cache properties inside of
> SQL statements. Does H2 have any support to process SQL hints? Can we
> change it?
>
> Having said that, while we finalize the above, I think we should start
> working on DDL implementation to use the default settings, as specified in
> Alexander's email.
>
> Also agree with the stop-the-world on the cache for index creation. We can
> always improve on it in future.
>
> D.
>
> On Wed, Jan 11, 2017 at 11:28 AM, Sergey Kozlov <skozlov@gridgain.com>
> wrote:
>
> > Hi
> >
> > I suppose we should put any ignite cache properties as additional
> > non-standard attributes after CREATE TABLE () clause as it does
> Postgress,
> > MySQL and other RDBMS.
> > Take a look on CREATE TABLE with using TABLESPACE (Postgess) or for
> CREATE
> > TABLE with using PARTITIONS (MySQL).
> >
> >
> >
> >
> >
> > On Wed, Jan 11, 2017 at 10:05 PM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > I believe custom synthax and parsing is a *must* for us, as well as for
> > any
> > > distributed database. At the very least we need to specify affinity key
> > > column somehow. Any cache property can be specified at the very end of
> > > table definition. Key columns can be determined as the ones with
> PRIMARY
> > > KEY constraint (Alex K. idea) + affinity column(s):
> > >
> > > CREATE TABLE employee (
> > >     id BIGINT PRIMARY KEY,
> > >     dept_id BIGINT AFFINITY KEY,
> > >     name VARCHAR(128),
> > >     address VARCHAR(256)
> > >     BACKUPS 2,
> > >     ATOMICITY_MODE ATOMIC,
> > > );
> > >
> > > "id" and "dept_id" form key type, "name" and "address" form value type.
> > >
> > > Vladimir.
> > >
> > > On Wed, Jan 11, 2017 at 9:08 PM, Alexey Kuznetsov <
> akuznetsov@apache.org
> > >
> > > wrote:
> > >
> > > > Hi, Alex!
> > > >
> > > > As far as I know most RDBMS allow something like: create table t1 (id
> > > > integer primary key, ....)
> > > > How about to take as key field that marked as "primary key"?
> > > >
> > > > As of atomicity and replication - I think it is a cache properties
> and
> > > with
> > > > create table we will create "types" in cache. No?
> > > > I thought that cache it is a kind of "schema" in RDBMS.
> > > >
> > > > Could you describe what will be created with CREATE TABLE?
> > > >
> > > > On Thu, Jan 12, 2017 at 12:54 AM, Alexander Paschenko <
> > > > alexander.a.paschenko@gmail.com> wrote:
> > > >
> > > > > Hello Igniters,
> > > > >
> > > > > I would like to start discussion about implementation of SQL DDL
> > > > commands.
> > > > >
> > > > > At the first stage, the most important ones seem to be CREATE TABLE
> > > > > (that will obviously correspond to creation of a cache) and CREATE
> > > > > INDEX.
> > > > >
> > > > > Regarding first one: SQL command for CREATE TABLE does not contain
> > any
> > > > > hints about cache settings (atomicity, replication, etc.), so these
> > > > > will probably be defined by some configuration properties (like
> > > > > ignite.ddl.default_cache_atomiticity, etc).
> > > > >
> > > > > Also it does not allow to distinguish between key and value
> columns -
> > > > > currently it is handled by keyFields property of QueryEntity, but
> it
> > > > > is unclear how to declare key fields via CREATE TABLE.
> > > > >
> > > > > So at a first glance it seems like we should either implement some
> > > > > sort of custom parsing (I believe Sergi will be against it) or
> > > > > introduce some kind of name prefix that would tell SQL engine that
> > > > > certain column is a key field column.
> > > > >
> > > > > Of course, this problem disappears is key is of SQL type.
> > > > >
> > > > > Regarding CREATE INDEX: probably at first we will have to implement
> > > > > this in "stop-the-world" manner, i.e. all cache will be blocked
> > during
> > > > > the index's initial buildup.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > Currently I'm working on parsing of those commands as that will be
> > > > > needed anyway and does not affect further implementation.
> > > > >
> > > > > - Alex
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

--94eb2c1b4e9a635db80545e1adb8--