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 <voze...@gridgain.com>:
>
> > 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.
> >
>
