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 <[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. > > > > > >
