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 <dsetrak...@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 <voze...@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 <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Fri, Feb 10, 2017 at 3:36 AM, Vladimir Ozerov <voze...@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.
> > >
> >
>
