Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAGt6o8nUi9ChTXmedn4M1+rAQ0-+5aSeoF=wwQ2A46ro_DHN=A@mail.gmail.com>
References: <CAGt6o8nWcZ+K4g5swxvYst3Mu+L+Kh67jrX1Gfs9p3Sg69as9A@mail.gmail.com>
 <CA+0=VoVx+zyNZwAc-qwgLJhs1mrNzuKFhBqnH7bXFvyzqShONw@mail.gmail.com> <CAGt6o8nUi9ChTXmedn4M1+rAQ0-+5aSeoF=wwQ2A46ro_DHN=A@mail.gmail.com>
From: Dmitriy Setrakyan <dsetrakyan@apache.org>
Date: Fri, 17 Feb 2017 10:15:43 -0800
Message-ID: <CA+0=VoU3ZVenMyuMJmJpnCHV0ff2mH6Cn3nbcVtd+9F+tHCjgg@mail.gmail.com>
Subject: Re: DML usability: routing single column to several object fields
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a114fd56c5405b90548bde94e
archived-at: Fri, 17 Feb 2017 18:16:27 -0000

--001a114fd56c5405b90548bde94e
Content-Type: text/plain; charset=UTF-8

Vladimir,

Still not clear. Why not create a proper mapping of a table attribute to a
key? If we don't support it today, do you think it will be feasible to add
such support?

D.

On Fri, Feb 17, 2017 at 12:25 AM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Dima,
>
> I am not sure we are talking about the same thing. My point is that
> currently single value is often mapped to several values in cache key-value
> pair. This is done for usability reasons, and the question is how to
> continue supporting this approach with DML. Let me show the problem again,
> consider the following value class:
>
> This is how users often work with Ignite:
>
> class Person {
>     long id;
>     String name;
> }
>
> IgniteCache<Long, Person> cache = ...;
>
> Person getById(long id) {
>     return cache.get(id);
> }
>
> DML doesn't support this approach at the moment, because we cannot map
> single attribute from DML statement to multiple destinations in key-value
> pair (_key + _val.Person.id). For this reason users will have to redefine
> their schema and do the following:
>
> IgniteCache<Long, String> cache = ...;
>
> Person getById(long id) {
>     return new Person(id, cache.get(id));
> }
>
> Only [DML + cache API] interaction is affected. No problems with [DML +
> SELECT] usages.
>
>
> On Thu, Feb 16, 2017 at 11:27 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > Vladimir,
> >
> > When a table is created, user should specify the "primary key". We can
> > extract this field and use it as the key into the BTree index. This way
> it
> > will fit into the current design. Am I wrong?
> >
> > D.
> >
> > On Thu, Feb 16, 2017 at 4:33 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Igniters,
> > >
> > > Consider the following pattern which is typically used by users when
> > > working through cache API and quering data through SQL at the same
> time:
> > >
> > > class Person {
> > >     @QuerySqlField
> > >     long id;
> > >
> > >     @QuerySqlField
> > >     String name;
> > > }
> > >
> > > cache.put(*id*, new Person(*id*, name));
> > >
> > > SELECT *id*, name FROM person;
> > >
> > > Notice that ID is stored twice per cache record - once for key, and
> once
> > > for value. This pattern is very convenient for users - loose some
> little
> > > space due to duplication on the one hand, but have self-contained value
> > > with all necessary data on the other. In fact virtually all production
> > > systems I saw followed this approach and had some minor duplication.
> > >
> > > It seems this approach doesn't work well with DML and upcoming DDL.
> When
> > > executing INSERT INTO Person VALUES (:id, :name), I specify two
> > attributes
> > > which must update three cache fields.
> > >
> > > In order to preserve usability of native cache API when DML is
> involved,
> > we
> > > need ability to map certain attribute to several Object properties.
> > > Probably this can be achieved with additional field property which
> > defines
> > > that it belongs to a group mapped to an attribute. May be existing
> > aliases
> > > could be used for this.
> > >
> > > Or we can ignore the problem sacrificing cache API usability a bit in
> > case
> > > of DML/DDL
> > >
> > > Any ideas on whether we need it, and how to design public API?
> > >
> > > Vladimir.
> > >
> >
>

--001a114fd56c5405b90548bde94e--