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
