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 < [email protected]> 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 <[email protected]> > 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 <[email protected] > > > > wrote: > > > > > Unique suffix is a good idea. > > > > > > Sergi > > > > > > 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <[email protected]>: > > > > > > > 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. > > > > > > > > > >
