Sergi,
This will require additional coordination between nodes, so I would not do
that for now. We have more serious problem here - binary metadata in
current implementation is not suited for DDL operations. We will feel it
better when start working on ALTER TABLE command, when single attribute
could change it's type in runtime, which is not supported by binary
metadata at the moment (this is append-only structure).
So I would put aside any questions around type names and metadata for now
and just let CREATE TABLE work. Hopefully in 2.2 we will have binary
metadata persistence, and align binary metadata with CREATE TABLE and ALTER
TABLE commands correctly.
On Wed, Jun 7, 2017 at 11:28 AM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:
> Vova,
>
> May be it makes sense to have an increasing version instead of UUID?
>
> Like sql_myschema_Person_1_Key.
>
> So that user will be able to pass just a table name `Person` to our API and
> receive a correct latest type name for that table.
>
> What do you think?
>
> Sergi
>
> 2017-06-07 11:20 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:
>
> > 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 <
> > valentin.kuliche...@gmail.com> 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 <
> dsetrak...@apache.org>
> > > 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 <
> > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
