Ok, let's put aside current fields configuration, I'll create separate
thread for it. As far as _KEY and _VAL, proposed change is exactly about
mappings:
class QueryEntity {
...
String keyFieldName;
String valFieldName;
...
}
The key thing is that we will not require users to be aware of our system
columns. Normally user should not bother about existence of hidden _KEY and
_VAL columns. Instead, we just allow them to optionally reference the whole
key and/or val through predefined name.
On Wed, Feb 15, 2017 at 3:07 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:
> 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 <voze...@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 <
> 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.
> > > > >
> > > >
> > >
> >
>
