Re: Key type name and value type name for CREATE TABLE
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: > 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 wrote: > > > Vova, > > > > > > > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov > > 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.kuliche...@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 < > dsetrak...@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.vlady...@gmail.com > > >>> > > >>> wrote: > > >>> > > Unique suffix is a good idea. > > > > Sergi > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > 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
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 Magdawrote: > Vova, > > > > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov > 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.kuliche...@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 > > >> 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.vlady...@gmail.com > >>> > >>> wrote: > >>> > Unique suffix is a good idea. > > Sergi > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > 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
Vova, > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerovwrote: > > 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.kuliche...@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 >> 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 >> >>> wrote: >>> Unique suffix is a good idea. Sergi 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > 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
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 Vladykinwrote: > 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 : > > > 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.kuliche...@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 < > dsetrak...@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.vlady...@gmail.com > > > > > > > > wrote: > > > > > > > > > Unique suffix is a good idea. > > > > > > > > > > Sergi > > > > > > > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > > > > > > > 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
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: > 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.kuliche...@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 > > 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.vlady...@gmail.com > > > > > > wrote: > > > > > > > Unique suffix is a good idea. > > > > > > > > Sergi > > > > > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > > > > > 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
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.kuliche...@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> 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 > > > wrote: > > > > > Unique suffix is a good idea. > > > > > > Sergi > > > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > > > 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
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 Setrakyanwrote: > 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 > wrote: > > > Unique suffix is a good idea. > > > > Sergi > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > 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
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 Setrakyanwrote: > 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 > wrote: > > > Unique suffix is a good idea. > > > > Sergi > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > > > 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
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 Vladykinwrote: > Unique suffix is a good idea. > > Sergi > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov : > > > 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
Unique suffix is a good idea. Sergi 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov: > 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. >