Denis,
>>> Inventing custom DDL statements is also a dead end.
Questionable. Every database has custom SQL, including DDL, are they all
"dead-ended"? Each database has unique set of feature and unique
architecture. The very goal of custom SQL is to give user control over
these differences. Without
Agree that schema-per-cache approach is natural for Ignite but will be a
nightmare for those who migrate from a RDBMS. Inventing custom DDL statements
is also a dead end. This won’t make users life and transitions from a RDBMS
easier.
Let’s to look at this differently. Most of us suggest the u
After looking at all the restrictions of "cache==schema" approach, I still
think that it would be the most natural match for Ignite. All other
suggestions are either too limiting, too hard, or not applicable for
Ignite.
My vote would be to start with "cache==schema" and get some user feedback.
We
On Mon, Jan 16, 2017 at 12:06 PM, Sergi Vladykin
wrote:
> Dima,
>
> I agree that cache==table is definitely a wrong choice, but as far as I see
> Vova suggests having cache==tablespace instead of cache==schema. I tend to
> agree with this decoupling of physical and logical grouping, but the
> con
Sergey,
See inline:
2017-01-17 0:50 GMT+03:00 Sergey Kozlov :
> For the approach schema==cache it is not clear how it works for some cases
> (especialy if SQL and regular cache operations are mixed):
>
> 1. I want to store two tables in same cache (same schema) and both tables
> have identical s
For the approach schema==cache it is not clear how it works for some cases
(especialy if SQL and regular cache operations are mixed):
1. I want to store two tables in same cache (same schema) and both tables
have identical structure like id Integer, name String.
How they will be processed for regu
Dima,
I agree that cache==table is definitely a wrong choice, but as far as I see
Vova suggests having cache==tablespace instead of cache==schema. I tend to
agree with this decoupling of physical and logical grouping, but the
concern is that it will require much more work to do.
Sergi
2017-01-16
Vova,
Currently I see only 2 ways we can proceed here:
1. cache == table
2. cache == schema
I agree that "cache==table" may be more flexible, but I don't think it will
work in Ignite.
We may end up with 1,000s of caches, which will carry significant overhead
on memory and cluster overall.
>
> Right, however, this section of the docs
>
> https://apacheignite.readme.io/docs/jcache#section-dynamic-cache
>
> does not clarify Ignite's behavior regarding dynamic caches when a new
> node joins the cluster. Will it just pick up dynamic cache
> configurations from the peers without being exp
Sergi,
Regarding CREATE SCHEMA/TABLE parsing:
2017-01-12 18:51 GMT+03:00 Sergi Vladykin :
> Hi,
>
> 1. For now I'm against inventing any custom SQL syntax and implementing
> parsing.
> Currently H2 supports the following syntax:
>
> CREATE TABLE test(...) WITH "myCustomParamString"
>
> This is en
Dima,
2017-01-13 21:20 GMT+03:00 Dmitriy Setrakyan :
> How about dynamic caches? Isn't the metadata already maintained across all
> nodes every time a new cache is created? What am I missing here?
Right, however, this section of the docs
https://apacheignite.readme.io/docs/jcache#section-dynamic
Sergi, Dima,
In the scope of Ignite 1.x it is perfectly fine to have "schema = cache".
Nobody suffers from it because nobody use Ignite as database. But in
future, thanks to page memory, we are going to target real database use
cases. Users will have multiple tables in Ignite. Plus views, triggers
On Fri, Jan 13, 2017 at 12:26 AM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:
> Dima,
>
> >> But, as you have justly noted, we have to keep nodes joining the
> >> cluster up-to-date about what schemas and tables need to be created in
> >> order for those nodes to participate in d
Vova,
I will join Sergi here. It seems like "schema = cache" will take care of
all different configuration properties required for different groups of
caches. In addition, it cleanly maps into current Ignite architecture. We
will need to have a very strong reason to move away from it.
D.
On Fri,
Could you please elaborate why it will not work this way?
Sergi
2017-01-13 12:39 GMT+03:00 Vladimir Ozerov :
> Correct, it worked, because Ignite has never had real database use case in
> mind. Unfortunately, if our global plans go as expected, it will not work
> for Ignite 2.x+.
>
> On Fri, Jan
Correct, it worked, because Ignite has never had real database use case in
mind. Unfortunately, if our global plans go as expected, it will not work
for Ignite 2.x+.
On Fri, Jan 13, 2017 at 11:53 AM, Sergi Vladykin
wrote:
> Lets move on with SQL schema == Ignite cache. It worked always like this
Lets move on with SQL schema == Ignite cache. It worked always like this, I
see no reasons to change this.
Sergi
2017-01-13 11:20 GMT+03:00 Vladimir Ozerov :
> "Tablespace" (Oracle, PostgreSQL) is what maps better than "schema" to our
> cache. But not ideally still.
>
> On Fri, Jan 13, 2017 at 1
"Tablespace" (Oracle, PostgreSQL) is what maps better than "schema" to our
cache. But not ideally still.
On Fri, Jan 13, 2017 at 11:10 AM, Vladimir Ozerov
wrote:
> Alex,
>
> Currently Ignite is not used as database. It is used as search engine -
> several types, several tables, several joins. Th
Alex,
Currently Ignite is not used as database. It is used as search engine -
several types, several tables, several joins. This is why having "SCHEMA ==
cache" was never a problem. Users have never build complex SQL applications
on top of Ignite. But we are going towards database. And my question
Vova,
2017-01-13 4:56 GMT+08:00 Vladimir Ozerov :
> 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 3
Dima,
>> But, as you have justly noted, we have to keep nodes joining the
>> cluster up-to-date about what schemas and tables need to be created in
>> order for those nodes to participate in distributed queries. And,
>> correct me if I'm wrong, but this is relevant even outside of context
>> of 2.
Alexander, not sure what is the point of creating a table without indexes.
I would combine stage 1 and 2.
On Thu, Jan 12, 2017 at 12:57 PM, Denis Magda wrote:
> Guys,
>
> As for the stages I would propose the following three creating separate
> JIRA tickets for them.
>
> Stage 1:
> - CREATE/DROP
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 concurre
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
flex
Denis
The affinity key term is close to the partition key definition for MySQL:
https://dev.mysql.com/doc/refman/5.7/en/partitioning-key.html
On Thu, Jan 12, 2017 at 11:46 PM, Denis Magda wrote:
>
> > On Jan 12, 2017, at 12:35 PM, Dmitriy Setrakyan
> wrote:
> >
> > On Thu, Jan 12, 2017 at 9:47
> On Jan 12, 2017, at 12:35 PM, Dmitriy Setrakyan wrote:
>
> On Thu, Jan 12, 2017 at 9:47 AM, Sergi Vladykin
> 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
>> "cac
On Thu, Jan 12, 2017 at 9:47 AM, Sergi Vladykin
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 i
On Thu, Jan 12, 2017 at 10:16 AM, Alexander Paschenko <
alexander.a.pasche...@gmail.com> wrote:
> Sergi,
>
> OK, great. Still, what's up with CREATE TABLE? After a bit of code
> digging, I currently don't see major obstacles against registering
> query entities (i.e. type descriptors) on the fly -
BTW, I have also did some H2 guts inspection, and, as I see it now,
it's not impossible to do custom parsing without (an awful lot) of
ugliness. What we would have to do is basically spoof private
singleton org.h2.engine.Engine#INSTANCE on node start via reflection
with our custom implementation th
Sergi,
OK, great. Still, what's up with CREATE TABLE? After a bit of code
digging, I currently don't see major obstacles against registering
query entities (i.e. type descriptors) on the fly - CREATE TABLE will
essentially boil down to *GridQueryIndexing#registerType* call.
But, as you have justl
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"
Sergi
2017-01-12 20:21 GMT+03:00 Alexander Paschenko <
alexander.a.pasche...@gmail.com>:
> Sergi,
Sergi, Alexey G.,
I see your point and am rather inclined to agree that we should let
current notion of "single schema - multiple tables" live.
Still, if we create schema with cache config file, what's the whole
point of SQL then if the user anyway has to write XML? This probably
could be useful
Hi,
1. For now I'm against inventing any custom SQL syntax and implementing
parsing.
Currently H2 supports the following syntax:
CREATE TABLE test(...) WITH "myCustomParamString"
This is enough for us to pass the needed parameters.
2. Agree with AG, we have to separate cache creation from table
I am afraid in this case user will have to define too much schemes -
boilerplate.
Does it make sense at all to pack multiple tuples into a single cache from
user perspective?
On Thu, Jan 12, 2017 at 4:40 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Alexander,
>
> Will we keep the o
Alexander,
Will we keep the old option to have multiple tables in one cache? If so,
how will create table statement know which cache to choose?
It seems to me that to be consistent with the current DML implementation we
should have a CREATE SCHEMA statement which will define the cache and cache
c
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,
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
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
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 con
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 t
40 matches
Mail list logo
