ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Key type name and value type name for CREATE TABLE
Date Thu, 08 Jun 2017 08:13:40 GMT
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 <dmagda@apache.org> wrote:

> Vova,
>
>
> > On Jun 7, 2017, at 1:20 AM, Vladimir Ozerov <vozerov@gridgain.com>
> 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 <
> > valentin.kulichenko@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 <dsetrakyan@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.vladykin@gmail.com
> >>>
> >>> wrote:
> >>>
> >>>> Unique suffix is a good idea.
> >>>>
> >>>> Sergi
> >>>>
> >>>> 2017-06-06 13:51 GMT+03:00 Vladimir Ozerov <vozerov@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.
> >>>>>
> >>>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message