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?
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 <dma...@apache.org> wrote: > > > On Jan 12, 2017, at 12:35 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > On Thu, Jan 12, 2017 at 9:47 AM, Sergi Vladykin < > sergi.vlady...@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 > >
