Alexander, not sure what is the point of creating a table without indexes. I would combine stage 1 and 2.
On Thu, Jan 12, 2017 at 12:57 PM, Denis Magda <dma...@apache.org> wrote: > Guys, > > As for the stages I would propose the following three creating separate > JIRA tickets for them. > > Stage 1: > - CREATE/DROP SCHEMA. > - CREATE/DROP TABLE. > > Stage 2: > - CREATE/DROP INDEX. > - indexes are updated in the ‘lock-the-world mode' > > Stage 3: > - CREATE/DROP INDEX. > - indexes are updated concurrently. > > Going further we might need to make up a command like ‘CREATE CLUSTER’ > that will be mapped to IgniteConfiguration. Using the command the user will > fill in the whole cluster configuration from DDL without a need to go to > XML at all. > > Thoughts? > > — > Denis > > > On Jan 12, 2017, at 12:41 AM, Sergey Kozlov <skoz...@gridgain.com> > wrote: > > > > 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 < > dsetrak...@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 <skoz...@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 < > voze...@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 < > >> akuznet...@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.pasche...@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 > >
