Vova,
> On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov <[email protected]> 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 < > [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. >>>>> >>>> >>> >>
