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
>

Reply via email to