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: <CAGt6o8nWztjoWtoATjy_Okxevv6E1W4U0veeR9KUx-xm8yb7Tw@mail.gmail.com>
References: <CAJhSPbqBUo7KfQFZQRTTH58kPoo00GcXY_4ZtdBCwoKF3aTOAw@mail.gmail.com>
 <CA+0=VoW6k8F-v2SGDME3P2=c6HAZ96cGN9rMm-i=S2BB3v41eQ@mail.gmail.com>
 <CAJhSPbrgDGHR5O++F5KN9mf42G87_4JOM8xj5nzxHJ91O9nA7g@mail.gmail.com>
 <CA+0=VoXn2L7wLbYOE15wm++UermtVMt8C=G_jodYGG_rNfNjiA@mail.gmail.com>
 <CAJhSPbrQhTM87u+urD0R15=7eFi3Sn__4dFcOaNdj-O_gYo3-A@mail.gmail.com>
 <CAJhSPbqNhxOh9QaShvFxo3r6FsO2bfNsTgcqVqn20XBjGbjEjQ@mail.gmail.com>
 <CAGt6o8=t5qOHWjFdG-m2x59_=TrB7mUA0sp+2Mk+NdgvqjiLdg@mail.gmail.com>
 <CA+0=VoXHUKp4vHyvtzbyjh49C49vCzvhE_s7FZuYT_xfkW88LQ@mail.gmail.com>
 <CAGt6o8nEXj4f_UR2OWVwFuUSHnQJtPaUEjVWtZESWAxMB7K_TA@mail.gmail.com>
 <CA+0=VoXDV3L9xhQjB99B2Tn5zh1FM6rEiXTD2bVadSSQt4o3vQ@mail.gmail.com> <CAGt6o8nWztjoWtoATjy_Okxevv6E1W4U0veeR9KUx-xm8yb7Tw@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Wed, 15 Feb 2017 15:07:32 +0300
Message-ID: <CA+eZwrEzx_Rmpd0hGw4RMPeDXpQSPPvw8m3+9dPaQXFd9HN4ww@mail.gmail.com>
Subject: Re: DML data streaming
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c193f30ea216d05489088df
archived-at: Wed, 15 Feb 2017 12:08:23 -0000

--94eb2c193f30ea216d05489088df
Content-Type: text/plain; charset=UTF-8

I don't see any improvement here. Usability will only suffer with this
change.

I'd suggest to just add mapping for system columns like _key, _val , _ver.

Sergi

2017-02-15 13:18 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:

> I think the whole QueryEntity class require rework to allow for this
> change. I would start with creating QueryField class which will encapsulate
> all field properties which are currently set through different setters:
>
> class QueryField {
>     String name;
>     String type;
>     String alias;
>     boolean keyField;
> }
>
> class QueryEntity {
>     String tableName;
>     String keyType;
>     String valType;
>     Collection<QueryField> fields;
>     Collection<QueryIndex> indexes;
> }
>
> Then we can add optional key and value field names to top-level config. If
> set, key and/or value will have names and will be included into SELECT *
> query in the same way as we do this for _KEY and _VAL at the moment:
>
> class QueryEntity {
>     String tableName;
>     String keyType;
>     String valType;
> *    String keyFieldName;*
> *    String valFieldName;*
>     Collection<QueryField> fields;
>     Collection<QueryIndex> indexes;
> }
>
> Any other ideas?
>
> On Tue, Feb 14, 2017 at 9:19 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>
> > Vova,
> >
> > Agree about the primitive types. However, it is not clear to me how the
> > mapping from a primitive type to a column name will be supported. Do you
> > have a design in mind?
> >
> > D.
> >
> > On Tue, Feb 14, 2017 at 6:16 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > Dima,
> > >
> > > This will not work for primitive keys and values as currently the only
> > way
> > > to address them is to use "_KEY" and "_VAL" aliases respectively. For
> > this
> > > reason I would rather postpone UPDATE/DELETE implementation until
> "_KEY"
> > > and "_VAL" are hidden from public API and some kind of mapping is
> > > introduced. AFAIK this should be handled as a part of IGNITE-3487 ]1].
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-3487
> > >
> > > On Sat, Feb 11, 2017 at 3:36 AM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > On Fri, Feb 10, 2017 at 3:36 AM, Vladimir Ozerov <
> vozerov@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > I propose to ship streaming with INSERT support only for now. This
> is
> > > > > enough for multitude cases and will add value to Ignite 1.9
> > > immediately.
> > > > We
> > > > > can think about correct streaming UPDATE/DELETE architecture
> > separately
> > > > .It
> > > > > is much more difficult thing, we cannot support it in a clean way
> > right
> > > > now
> > > > > due to multiple "_key" and "_val" usages over the code base.
> > > > >
> > > >
> > > > Vova, I disagree. If all parts of the key are present, then we can
> > always
> > > > construct a key in all cases. For these operations we can always
> > support
> > > > streaming. For all other operations, we can delegate to standard MR,
> > but
> > > > still perform most operations on the same node, as I suggested in
> > another
> > > > email.
> > > >
> > >
> >
>

--94eb2c193f30ea216d05489088df--