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 <[email protected]>: > 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 <[email protected]> wrote: > > > 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. > > >>>>> > > >>>> > > >>> > > >> > > > > >
