ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kuznetsov <akuznet...@apache.org>
Subject Re: DDL implementation details
Date Wed, 11 Jan 2017 18:08:15 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message