ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Key type name and value type name for CREATE TABLE
Date Thu, 08 Jun 2017 10:20:15 GMT
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 <vozerov@gridgain.com>:

> 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