You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/06/06 10:51:01 UTC
Key type name and value type name for CREATE TABLE
Igniters,
In the very first implementation of CREATE TABLE we applied the following
rule to key and value type names:
keyTypeName == tableName + "Key"
valTypeName == tableName
E.g.:
CREATE TABLE Person ...
keyTypeName == PERSONKey
valTypeName == PERSON
After that user could potentially create objects with these type names
manually and add them to cache through native Ignite API:
BinaryObject key = IgniteBinary.builder("PERSONKey").addField().build();
BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
IgniteCache.put(key, val);
This approach has two problems:
1) Type names are not unique between different tables. it means that if two
tables with the same name are created in different schemas, we got a
conflict.
2) Type names are bound to binary metadata, so if user decides to do the
following, he will receive and error about incompatible metadata:
CREATE TABLE Person (id INT PRIMARY KEY);
DROP TABLE Person;
CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta still
has type "Integer".
In order to avoid that I am going to add unique suffix or so (say, UUID) to
type names. This way there will be no human-readable type names any more,
but there will be no conflicts either. In future releases we will relax
this somehow.
Thoughts?
Vladimir.
Re: Key type name and value type name for CREATE TABLE
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Sergi,
This will require additional coordination between nodes, so I would not do
that for now. We have more serious problem here - binary metadata in
current implementation is not suited for DDL operations. We will feel it
better when start working on ALTER TABLE command, when single attribute
could change it's type in runtime, which is not supported by binary
metadata at the moment (this is append-only structure).
So I would put aside any questions around type names and metadata for now
and just let CREATE TABLE work. Hopefully in 2.2 we will have binary
metadata persistence, and align binary metadata with CREATE TABLE and ALTER
TABLE commands correctly.
On Wed, Jun 7, 2017 at 11:28 AM, Sergi Vladykin <se...@gmail.com>
wrote:
> Vova,
>
> May be it makes sense to have an increasing version instead of UUID?
>
> Like sql_myschema_Person_1_Key.
>
> So that user will be able to pass just a table name `Person` to our API and
> receive a correct latest type name for that table.
>
> What do you think?
>
> Sergi
>
> 2017-06-07 11:20 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>
> > Valya,
> >
> > It doesn't affect builder invoked from DML engine, as it know how to find
> > these names. As per users who want to call IgniteCache.put() on a cache
> > created through SQL - sorry, they will have hard times resolving actual
> > type name. This is OK for the first release, provided that we mask type
> > names for a reason - to avoid subtle exceptions when working with DDL and
> > DML.
> >
> > On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> >
> > > Vova,
> > >
> > > If you add unique suffix losing human-readable type names, how will the
> > > builder approach work? Maybe it makes sense to add an API call that
> > returns
> > > current type name for a table?
> > >
> > > -Val
> > >
> > > On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > Vova,
> > > >
> > > > I am not sure I like the key type name the way it is. Can we add some
> > > > separator between the table name and key name, like "_". To me
> > > "PERSON_KEY"
> > > > reads a lot better than "PERSONKey".
> > > >
> > > > D.
> > > >
> > > > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> > sergi.vladykin@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Unique suffix is a good idea.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > In the very first implementation of CREATE TABLE we applied the
> > > > following
> > > > > > rule to key and value type names:
> > > > > > keyTypeName == tableName + "Key"
> > > > > > valTypeName == tableName
> > > > > >
> > > > > > E.g.:
> > > > > > CREATE TABLE Person ...
> > > > > > keyTypeName == PERSONKey
> > > > > > valTypeName == PERSON
> > > > > >
> > > > > > After that user could potentially create objects with these type
> > > names
> > > > > > manually and add them to cache through native Ignite API:
> > > > > >
> > > > > > BinaryObject key =
> > > > IgniteBinary.builder("PERSONKey").addField().build();
> > > > > > BinaryObject val = IgniteBinary.builder("PERSON")
> > > .addField().build();
> > > > > > IgniteCache.put(key, val);
> > > > > >
> > > > > > This approach has two problems:
> > > > > > 1) Type names are not unique between different tables. it means
> > that
> > > if
> > > > > two
> > > > > > tables with the same name are created in different schemas, we
> got
> > a
> > > > > > conflict.
> > > > > > 2) Type names are bound to binary metadata, so if user decides to
> > do
> > > > the
> > > > > > following, he will receive and error about incompatible metadata:
> > > > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > > > DROP TABLE Person;
> > > > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old
> > meta
> > > > > still
> > > > > > has type "Integer".
> > > > > >
> > > > > > In order to avoid that I am going to add unique suffix or so
> (say,
> > > > UUID)
> > > > > to
> > > > > > type names. This way there will be no human-readable type names
> any
> > > > more,
> > > > > > but there will be no conflicts either. In future releases we will
> > > relax
> > > > > > this somehow.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Sergi Vladykin <se...@gmail.com>.
Vova,
May be it makes sense to have an increasing version instead of UUID?
Like sql_myschema_Person_1_Key.
So that user will be able to pass just a table name `Person` to our API and
receive a correct latest type name for that table.
What do you think?
Sergi
2017-06-07 11:20 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Valya,
>
> It doesn't affect builder invoked from DML engine, as it know how to find
> these names. As per users who want to call IgniteCache.put() on a cache
> created through SQL - sorry, they will have hard times resolving actual
> type name. This is OK for the first release, provided that we mask type
> names for a reason - to avoid subtle exceptions when working with DDL and
> DML.
>
> On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Vova,
> >
> > If you add unique suffix losing human-readable type names, how will the
> > builder approach work? Maybe it makes sense to add an API call that
> returns
> > current type name for a table?
> >
> > -Val
> >
> > On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> >
> > > Vova,
> > >
> > > I am not sure I like the key type name the way it is. Can we add some
> > > separator between the table name and key name, like "_". To me
> > "PERSON_KEY"
> > > reads a lot better than "PERSONKey".
> > >
> > > D.
> > >
> > > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> sergi.vladykin@gmail.com
> > >
> > > wrote:
> > >
> > > > Unique suffix is a good idea.
> > > >
> > > > Sergi
> > > >
> > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > > >
> > > > > Igniters,
> > > > >
> > > > > In the very first implementation of CREATE TABLE we applied the
> > > following
> > > > > rule to key and value type names:
> > > > > keyTypeName == tableName + "Key"
> > > > > valTypeName == tableName
> > > > >
> > > > > E.g.:
> > > > > CREATE TABLE Person ...
> > > > > keyTypeName == PERSONKey
> > > > > valTypeName == PERSON
> > > > >
> > > > > After that user could potentially create objects with these type
> > names
> > > > > manually and add them to cache through native Ignite API:
> > > > >
> > > > > BinaryObject key =
> > > IgniteBinary.builder("PERSONKey").addField().build();
> > > > > BinaryObject val = IgniteBinary.builder("PERSON")
> > .addField().build();
> > > > > IgniteCache.put(key, val);
> > > > >
> > > > > This approach has two problems:
> > > > > 1) Type names are not unique between different tables. it means
> that
> > if
> > > > two
> > > > > tables with the same name are created in different schemas, we got
> a
> > > > > conflict.
> > > > > 2) Type names are bound to binary metadata, so if user decides to
> do
> > > the
> > > > > following, he will receive and error about incompatible metadata:
> > > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > > DROP TABLE Person;
> > > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old
> meta
> > > > still
> > > > > has type "Integer".
> > > > >
> > > > > In order to avoid that I am going to add unique suffix or so (say,
> > > UUID)
> > > > to
> > > > > type names. This way there will be no human-readable type names any
> > > more,
> > > > > but there will be no conflicts either. In future releases we will
> > relax
> > > > > this somehow.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Vladimir.
> > > > >
> > > >
> > >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Sergi Vladykin <se...@gmail.com>.
I don't think we should restrict any existing API usage with no good
reason. Lets just add some API for type name resolving.
Sergi
2017-06-08 11:13 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Denis,
>
> It is impossible to have simple type names and cache names in common case.
> E.g.:
> Schema 1: CREATE TABLE Person (...)
> Schema 2: CREATE TABLE Person (...)
>
> There definitely will be a number of limitations when working with SQL and
> non-SQL caches, we just do not see them all at the moment. For this reason,
> we'd better to treat IgniteCache.put() on SQL cache as an invalid use case
> with undefined behavior (though, technically it works in 2.1).
>
> On Thu, Jun 8, 2017 at 6:09 AM, Denis Magda <dm...@apache.org> wrote:
>
> > Vova,
> >
> >
> > > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> > >
> > > Valya,
> > >
> > > It doesn't affect builder invoked from DML engine, as it know how to
> find
> > > these names. As per users who want to call IgniteCache.put() on a cache
> > > created through SQL - sorry, they will have hard times resolving actual
> > > type name.
> >
> > If this limitation is to be addressed in the future release then I don’t
> > have any concerns. Is it so?
> >
> > Ideally, regardless how a cache was created and its SQL schema was
> defined
> > (DDL, Spring XML and Java config), the user should be able to works with
> it
> > using all the APIs available w/o limitations.
> >
> > —
> > Denis
> >
> > > This is OK for the first release, provided that we mask type
> > > names for a reason - to avoid subtle exceptions when working with DDL
> and
> > > DML.
> > >
> > > On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com> wrote:
> > >
> > >> Vova,
> > >>
> > >> If you add unique suffix losing human-readable type names, how will
> the
> > >> builder approach work? Maybe it makes sense to add an API call that
> > returns
> > >> current type name for a table?
> > >>
> > >> -Val
> > >>
> > >> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > >> wrote:
> > >>
> > >>> Vova,
> > >>>
> > >>> I am not sure I like the key type name the way it is. Can we add some
> > >>> separator between the table name and key name, like "_". To me
> > >> "PERSON_KEY"
> > >>> reads a lot better than "PERSONKey".
> > >>>
> > >>> D.
> > >>>
> > >>> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> > sergi.vladykin@gmail.com
> > >>>
> > >>> wrote:
> > >>>
> > >>>> Unique suffix is a good idea.
> > >>>>
> > >>>> Sergi
> > >>>>
> > >>>> 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > >>>>
> > >>>>> Igniters,
> > >>>>>
> > >>>>> In the very first implementation of CREATE TABLE we applied the
> > >>> following
> > >>>>> rule to key and value type names:
> > >>>>> keyTypeName == tableName + "Key"
> > >>>>> valTypeName == tableName
> > >>>>>
> > >>>>> E.g.:
> > >>>>> CREATE TABLE Person ...
> > >>>>> keyTypeName == PERSONKey
> > >>>>> valTypeName == PERSON
> > >>>>>
> > >>>>> After that user could potentially create objects with these type
> > >> names
> > >>>>> manually and add them to cache through native Ignite API:
> > >>>>>
> > >>>>> BinaryObject key =
> > >>> IgniteBinary.builder("PERSONKey").addField().build();
> > >>>>> BinaryObject val = IgniteBinary.builder("PERSON")
> > >> .addField().build();
> > >>>>> IgniteCache.put(key, val);
> > >>>>>
> > >>>>> This approach has two problems:
> > >>>>> 1) Type names are not unique between different tables. it means
> that
> > >> if
> > >>>> two
> > >>>>> tables with the same name are created in different schemas, we got
> a
> > >>>>> conflict.
> > >>>>> 2) Type names are bound to binary metadata, so if user decides to
> do
> > >>> the
> > >>>>> following, he will receive and error about incompatible metadata:
> > >>>>> CREATE TABLE Person (id INT PRIMARY KEY);
> > >>>>> DROP TABLE Person;
> > >>>>> CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old
> meta
> > >>>> still
> > >>>>> has type "Integer".
> > >>>>>
> > >>>>> In order to avoid that I am going to add unique suffix or so (say,
> > >>> UUID)
> > >>>> to
> > >>>>> type names. This way there will be no human-readable type names any
> > >>> more,
> > >>>>> but there will be no conflicts either. In future releases we will
> > >> relax
> > >>>>> this somehow.
> > >>>>>
> > >>>>> Thoughts?
> > >>>>>
> > >>>>> Vladimir.
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Denis,
It is impossible to have simple type names and cache names in common case.
E.g.:
Schema 1: CREATE TABLE Person (...)
Schema 2: CREATE TABLE Person (...)
There definitely will be a number of limitations when working with SQL and
non-SQL caches, we just do not see them all at the moment. For this reason,
we'd better to treat IgniteCache.put() on SQL cache as an invalid use case
with undefined behavior (though, technically it works in 2.1).
On Thu, Jun 8, 2017 at 6:09 AM, Denis Magda <dm...@apache.org> wrote:
> Vova,
>
>
> > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov <vo...@gridgain.com>
> wrote:
> >
> > Valya,
> >
> > It doesn't affect builder invoked from DML engine, as it know how to find
> > these names. As per users who want to call IgniteCache.put() on a cache
> > created through SQL - sorry, they will have hard times resolving actual
> > type name.
>
> If this limitation is to be addressed in the future release then I don’t
> have any concerns. Is it so?
>
> Ideally, regardless how a cache was created and its SQL schema was defined
> (DDL, Spring XML and Java config), the user should be able to works with it
> using all the APIs available w/o limitations.
>
> —
> Denis
>
> > This is OK for the first release, provided that we mask type
> > names for a reason - to avoid subtle exceptions when working with DDL and
> > DML.
> >
> > On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> >
> >> Vova,
> >>
> >> If you add unique suffix losing human-readable type names, how will the
> >> builder approach work? Maybe it makes sense to add an API call that
> returns
> >> current type name for a table?
> >>
> >> -Val
> >>
> >> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> >> wrote:
> >>
> >>> Vova,
> >>>
> >>> I am not sure I like the key type name the way it is. Can we add some
> >>> separator between the table name and key name, like "_". To me
> >> "PERSON_KEY"
> >>> reads a lot better than "PERSONKey".
> >>>
> >>> D.
> >>>
> >>> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <
> sergi.vladykin@gmail.com
> >>>
> >>> wrote:
> >>>
> >>>> Unique suffix is a good idea.
> >>>>
> >>>> Sergi
> >>>>
> >>>> 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >>>>
> >>>>> Igniters,
> >>>>>
> >>>>> In the very first implementation of CREATE TABLE we applied the
> >>> following
> >>>>> rule to key and value type names:
> >>>>> keyTypeName == tableName + "Key"
> >>>>> valTypeName == tableName
> >>>>>
> >>>>> E.g.:
> >>>>> CREATE TABLE Person ...
> >>>>> keyTypeName == PERSONKey
> >>>>> valTypeName == PERSON
> >>>>>
> >>>>> After that user could potentially create objects with these type
> >> names
> >>>>> manually and add them to cache through native Ignite API:
> >>>>>
> >>>>> BinaryObject key =
> >>> IgniteBinary.builder("PERSONKey").addField().build();
> >>>>> BinaryObject val = IgniteBinary.builder("PERSON")
> >> .addField().build();
> >>>>> IgniteCache.put(key, val);
> >>>>>
> >>>>> This approach has two problems:
> >>>>> 1) Type names are not unique between different tables. it means that
> >> if
> >>>> two
> >>>>> tables with the same name are created in different schemas, we got a
> >>>>> conflict.
> >>>>> 2) Type names are bound to binary metadata, so if user decides to do
> >>> the
> >>>>> following, he will receive and error about incompatible metadata:
> >>>>> CREATE TABLE Person (id INT PRIMARY KEY);
> >>>>> DROP TABLE Person;
> >>>>> CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> >>>> still
> >>>>> has type "Integer".
> >>>>>
> >>>>> In order to avoid that I am going to add unique suffix or so (say,
> >>> UUID)
> >>>> to
> >>>>> type names. This way there will be no human-readable type names any
> >>> more,
> >>>>> but there will be no conflicts either. In future releases we will
> >> relax
> >>>>> this somehow.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Vladimir.
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Key type name and value type name for CREATE TABLE
Posted by Denis Magda <dm...@apache.org>.
Vova,
> On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov <vo...@gridgain.com> wrote:
>
> Valya,
>
> It doesn't affect builder invoked from DML engine, as it know how to find
> these names. As per users who want to call IgniteCache.put() on a cache
> created through SQL - sorry, they will have hard times resolving actual
> type name.
If this limitation is to be addressed in the future release then I don’t have any concerns. Is it so?
Ideally, regardless how a cache was created and its SQL schema was defined (DDL, Spring XML and Java config), the user should be able to works with it using all the APIs available w/o limitations.
—
Denis
> This is OK for the first release, provided that we mask type
> names for a reason - to avoid subtle exceptions when working with DDL and
> DML.
>
> On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
>> Vova,
>>
>> If you add unique suffix losing human-readable type names, how will the
>> builder approach work? Maybe it makes sense to add an API call that returns
>> current type name for a table?
>>
>> -Val
>>
>> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <ds...@apache.org>
>> wrote:
>>
>>> Vova,
>>>
>>> I am not sure I like the key type name the way it is. Can we add some
>>> separator between the table name and key name, like "_". To me
>> "PERSON_KEY"
>>> reads a lot better than "PERSONKey".
>>>
>>> D.
>>>
>>> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <sergi.vladykin@gmail.com
>>>
>>> wrote:
>>>
>>>> Unique suffix is a good idea.
>>>>
>>>> Sergi
>>>>
>>>> 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>>>>
>>>>> Igniters,
>>>>>
>>>>> In the very first implementation of CREATE TABLE we applied the
>>> following
>>>>> rule to key and value type names:
>>>>> keyTypeName == tableName + "Key"
>>>>> valTypeName == tableName
>>>>>
>>>>> E.g.:
>>>>> CREATE TABLE Person ...
>>>>> keyTypeName == PERSONKey
>>>>> valTypeName == PERSON
>>>>>
>>>>> After that user could potentially create objects with these type
>> names
>>>>> manually and add them to cache through native Ignite API:
>>>>>
>>>>> BinaryObject key =
>>> IgniteBinary.builder("PERSONKey").addField().build();
>>>>> BinaryObject val = IgniteBinary.builder("PERSON")
>> .addField().build();
>>>>> IgniteCache.put(key, val);
>>>>>
>>>>> This approach has two problems:
>>>>> 1) Type names are not unique between different tables. it means that
>> if
>>>> two
>>>>> tables with the same name are created in different schemas, we got a
>>>>> conflict.
>>>>> 2) Type names are bound to binary metadata, so if user decides to do
>>> the
>>>>> following, he will receive and error about incompatible metadata:
>>>>> CREATE TABLE Person (id INT PRIMARY KEY);
>>>>> DROP TABLE Person;
>>>>> CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
>>>> still
>>>>> has type "Integer".
>>>>>
>>>>> In order to avoid that I am going to add unique suffix or so (say,
>>> UUID)
>>>> to
>>>>> type names. This way there will be no human-readable type names any
>>> more,
>>>>> but there will be no conflicts either. In future releases we will
>> relax
>>>>> this somehow.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Vladimir.
>>>>>
>>>>
>>>
>>
Re: Key type name and value type name for CREATE TABLE
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Valya,
It doesn't affect builder invoked from DML engine, as it know how to find
these names. As per users who want to call IgniteCache.put() on a cache
created through SQL - sorry, they will have hard times resolving actual
type name. This is OK for the first release, provided that we mask type
names for a reason - to avoid subtle exceptions when working with DDL and
DML.
On Wed, Jun 7, 2017 at 5:50 AM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> Vova,
>
> If you add unique suffix losing human-readable type names, how will the
> builder approach work? Maybe it makes sense to add an API call that returns
> current type name for a table?
>
> -Val
>
> On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > Vova,
> >
> > I am not sure I like the key type name the way it is. Can we add some
> > separator between the table name and key name, like "_". To me
> "PERSON_KEY"
> > reads a lot better than "PERSONKey".
> >
> > D.
> >
> > On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <sergi.vladykin@gmail.com
> >
> > wrote:
> >
> > > Unique suffix is a good idea.
> > >
> > > Sergi
> > >
> > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> > >
> > > > Igniters,
> > > >
> > > > In the very first implementation of CREATE TABLE we applied the
> > following
> > > > rule to key and value type names:
> > > > keyTypeName == tableName + "Key"
> > > > valTypeName == tableName
> > > >
> > > > E.g.:
> > > > CREATE TABLE Person ...
> > > > keyTypeName == PERSONKey
> > > > valTypeName == PERSON
> > > >
> > > > After that user could potentially create objects with these type
> names
> > > > manually and add them to cache through native Ignite API:
> > > >
> > > > BinaryObject key =
> > IgniteBinary.builder("PERSONKey").addField().build();
> > > > BinaryObject val = IgniteBinary.builder("PERSON")
> .addField().build();
> > > > IgniteCache.put(key, val);
> > > >
> > > > This approach has two problems:
> > > > 1) Type names are not unique between different tables. it means that
> if
> > > two
> > > > tables with the same name are created in different schemas, we got a
> > > > conflict.
> > > > 2) Type names are bound to binary metadata, so if user decides to do
> > the
> > > > following, he will receive and error about incompatible metadata:
> > > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > > DROP TABLE Person;
> > > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> > > still
> > > > has type "Integer".
> > > >
> > > > In order to avoid that I am going to add unique suffix or so (say,
> > UUID)
> > > to
> > > > type names. This way there will be no human-readable type names any
> > more,
> > > > but there will be no conflicts either. In future releases we will
> relax
> > > > this somehow.
> > > >
> > > > Thoughts?
> > > >
> > > > Vladimir.
> > > >
> > >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Valentin Kulichenko <va...@gmail.com>.
Vova,
If you add unique suffix losing human-readable type names, how will the
builder approach work? Maybe it makes sense to add an API call that returns
current type name for a table?
-Val
On Tue, Jun 6, 2017 at 7:43 PM Dmitriy Setrakyan <ds...@apache.org>
wrote:
> Vova,
>
> I am not sure I like the key type name the way it is. Can we add some
> separator between the table name and key name, like "_". To me "PERSON_KEY"
> reads a lot better than "PERSONKey".
>
> D.
>
> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > Unique suffix is a good idea.
> >
> > Sergi
> >
> > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >
> > > Igniters,
> > >
> > > In the very first implementation of CREATE TABLE we applied the
> following
> > > rule to key and value type names:
> > > keyTypeName == tableName + "Key"
> > > valTypeName == tableName
> > >
> > > E.g.:
> > > CREATE TABLE Person ...
> > > keyTypeName == PERSONKey
> > > valTypeName == PERSON
> > >
> > > After that user could potentially create objects with these type names
> > > manually and add them to cache through native Ignite API:
> > >
> > > BinaryObject key =
> IgniteBinary.builder("PERSONKey").addField().build();
> > > BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
> > > IgniteCache.put(key, val);
> > >
> > > This approach has two problems:
> > > 1) Type names are not unique between different tables. it means that if
> > two
> > > tables with the same name are created in different schemas, we got a
> > > conflict.
> > > 2) Type names are bound to binary metadata, so if user decides to do
> the
> > > following, he will receive and error about incompatible metadata:
> > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > DROP TABLE Person;
> > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> > still
> > > has type "Integer".
> > >
> > > In order to avoid that I am going to add unique suffix or so (say,
> UUID)
> > to
> > > type names. This way there will be no human-readable type names any
> more,
> > > but there will be no conflicts either. In future releases we will relax
> > > this somehow.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Vladimir Ozerov <vo...@gridgain.com>.
Dima,
Currently key and val type names for the table "myschema"."Person" will be
something like this.
key: "sql_myschema_Person_[RANDOM_UUID]_Key"
val: "sql_myschema_Person_[RANDOM_UUID]"
On Wed, Jun 7, 2017 at 5:42 AM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> Vova,
>
> I am not sure I like the key type name the way it is. Can we add some
> separator between the table name and key name, like "_". To me "PERSON_KEY"
> reads a lot better than "PERSONKey".
>
> D.
>
> On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > Unique suffix is a good idea.
> >
> > Sergi
> >
> > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> >
> > > Igniters,
> > >
> > > In the very first implementation of CREATE TABLE we applied the
> following
> > > rule to key and value type names:
> > > keyTypeName == tableName + "Key"
> > > valTypeName == tableName
> > >
> > > E.g.:
> > > CREATE TABLE Person ...
> > > keyTypeName == PERSONKey
> > > valTypeName == PERSON
> > >
> > > After that user could potentially create objects with these type names
> > > manually and add them to cache through native Ignite API:
> > >
> > > BinaryObject key = IgniteBinary.builder("
> PERSONKey").addField().build();
> > > BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
> > > IgniteCache.put(key, val);
> > >
> > > This approach has two problems:
> > > 1) Type names are not unique between different tables. it means that if
> > two
> > > tables with the same name are created in different schemas, we got a
> > > conflict.
> > > 2) Type names are bound to binary metadata, so if user decides to do
> the
> > > following, he will receive and error about incompatible metadata:
> > > CREATE TABLE Person (id INT PRIMARY KEY);
> > > DROP TABLE Person;
> > > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> > still
> > > has type "Integer".
> > >
> > > In order to avoid that I am going to add unique suffix or so (say,
> UUID)
> > to
> > > type names. This way there will be no human-readable type names any
> more,
> > > but there will be no conflicts either. In future releases we will relax
> > > this somehow.
> > >
> > > Thoughts?
> > >
> > > Vladimir.
> > >
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Vova,
I am not sure I like the key type name the way it is. Can we add some
separator between the table name and key name, like "_". To me "PERSON_KEY"
reads a lot better than "PERSONKey".
D.
On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin <se...@gmail.com>
wrote:
> Unique suffix is a good idea.
>
> Sergi
>
> 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>
> > Igniters,
> >
> > In the very first implementation of CREATE TABLE we applied the following
> > rule to key and value type names:
> > keyTypeName == tableName + "Key"
> > valTypeName == tableName
> >
> > E.g.:
> > CREATE TABLE Person ...
> > keyTypeName == PERSONKey
> > valTypeName == PERSON
> >
> > After that user could potentially create objects with these type names
> > manually and add them to cache through native Ignite API:
> >
> > BinaryObject key = IgniteBinary.builder("PERSONKey").addField().build();
> > BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
> > IgniteCache.put(key, val);
> >
> > This approach has two problems:
> > 1) Type names are not unique between different tables. it means that if
> two
> > tables with the same name are created in different schemas, we got a
> > conflict.
> > 2) Type names are bound to binary metadata, so if user decides to do the
> > following, he will receive and error about incompatible metadata:
> > CREATE TABLE Person (id INT PRIMARY KEY);
> > DROP TABLE Person;
> > CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta
> still
> > has type "Integer".
> >
> > In order to avoid that I am going to add unique suffix or so (say, UUID)
> to
> > type names. This way there will be no human-readable type names any more,
> > but there will be no conflicts either. In future releases we will relax
> > this somehow.
> >
> > Thoughts?
> >
> > Vladimir.
> >
>
Re: Key type name and value type name for CREATE TABLE
Posted by Sergi Vladykin <se...@gmail.com>.
Unique suffix is a good idea.
Sergi
2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
> Igniters,
>
> In the very first implementation of CREATE TABLE we applied the following
> rule to key and value type names:
> keyTypeName == tableName + "Key"
> valTypeName == tableName
>
> E.g.:
> CREATE TABLE Person ...
> keyTypeName == PERSONKey
> valTypeName == PERSON
>
> After that user could potentially create objects with these type names
> manually and add them to cache through native Ignite API:
>
> BinaryObject key = IgniteBinary.builder("PERSONKey").addField().build();
> BinaryObject val = IgniteBinary.builder("PERSON").addField().build();
> IgniteCache.put(key, val);
>
> This approach has two problems:
> 1) Type names are not unique between different tables. it means that if two
> tables with the same name are created in different schemas, we got a
> conflict.
> 2) Type names are bound to binary metadata, so if user decides to do the
> following, he will receive and error about incompatible metadata:
> CREATE TABLE Person (id INT PRIMARY KEY);
> DROP TABLE Person;
> CREATE TABLE Person(in BIGINT PRIMARY KEY); // Fail because old meta still
> has type "Integer".
>
> In order to avoid that I am going to add unique suffix or so (say, UUID) to
> type names. This way there will be no human-readable type names any more,
> but there will be no conflicts either. In future releases we will relax
> this somehow.
>
> Thoughts?
>
> Vladimir.
>