ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Paschenko <alexander.a.pasche...@gmail.com>
Subject Re: DDL implementation details
Date Fri, 13 Jan 2017 07:33:15 GMT
Vova,

2017-01-13 4:56 GMT+08:00 Vladimir Ozerov <vozerov@gridgain.com>:
> I am not quite sure I understand the idea of "SCHEMA == cache". Consider
> some small database with, say, ~30 tables. And user wants to migrate to
> Ignite. How is he supposed to do so? 30 schemas leading to rewrite of all
> his SQL scripts? Or 30 key-value pairs in a single cache leading to lack of
> flexibility and performance problems?

But currently schema *is* semantically equal to cache while table is
equal to type descriptor (i.e. type of stored entities), nothing new
here.

Say, in single cache we may have entities of types Person and
Organization, those map to two tables with same names, and can be
accessed within the same cache (i.e. schema).

If we want to limit the user with having single type descriptor per
cache (i.e. cache has only one type of stored entities - BTW, where we
are with this 2.0-wise?), then this notion could change. But currently
what has been suggested already fits quite good with what we do have
at the moment regarding semantic of SQL objects.

- Alex

> Another example is how to deal with referene tables? Lots database has
> small reference tables which is best to fit REPLICATED cache, while others
> are usually bound to PARTITIONED mode. "SCHEMA == cache" will force users
> to split them into separate schemes leading to poor user experience.
>
> I understand that we may have some implementation details around it at the
> moment. But from user perspective "SCHEMA == cache" doesn't make sense. As
> we are going towards AI 2.0 we'd better to rethink this approach.
>
> On Thu, Jan 12, 2017 at 11:46 PM, Denis Magda <dmagda@apache.org> wrote:
>
>>
>> > On Jan 12, 2017, at 12:35 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
>> wrote:
>> >
>> > On Thu, Jan 12, 2017 at 9:47 AM, Sergi Vladykin <
>> sergi.vladykin@gmail.com>
>> > wrote:
>> >
>> >> The xml config was only for example. We can put in this configuration
>> >> string cache config parameters directly like this:
>> >>
>> >> CREATE SCHEMA "MyCacheName" WITH
>> >> "cacheMode=REPLICATED;atomicityMode=ATOMIC"
>> >>
>> >
>> > This approach makes sense, if it can be easily supported with H2.
>>
>> What’s for affinity keys? Can we make an exception for them by defining in
>> this part of the statement
>>
>> CREATE TABLE employee (
>>    id BIGINT PRIMARY KEY,
>>    dept_id BIGINT AFFINITY KEY,
>>    name VARCHAR(128),
>> );
>>
>> or that l
>>
>> CREATE TABLE employee (
>>    id BIGINT PRIMARY KEY,
>>    dept_id BIGINT,
>>    name VARCHAR(128),
>>    CONSTRAINT affKey AFFINITY KEY(dept_id)
>> );
>>
>> ?
>>
>> —
>> Denis
>>
>>

Mime
View raw message