Vladimir, I am not sure I understand your point. The value type name should
be the table name, no?
On Thu, Feb 16, 2017 at 12:13 AM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Dima,
>
> At this point we require the following additional data which is outside of
> standard SQL:
> - Key type
> - Value type
> - Set of key columns
>
> I do not know yet how we will define these values. At the very least we can
> calculate them automatically in some cases. For "keyFieldName" and
> "valFieldName" things are easier, as we can always derive them from table
> definition.
>
> Example 1 - primitives:
>
> CREATE TABLE (
> *pk_id* BIGINT PRIMARY KEY,
> *val* BIGINT
> )
>
> keyFieldName = "*pk_id*", valFieldName = "*val*"
>
> Example 2 - composites:
>
> CREATE TABLE (
> *pk_id* BIGINT PRIMARY KEY,
> val1 BIGINT,
> val2 VARCHAR
> )
>
> keyFieldName = "*pk_id*", valFieldName = null (because value is complex and
> is composed of two attributes).
>
> Vladimir.
>
>
> On Wed, Feb 15, 2017 at 11:42 PM, Dmitriy Setrakyan <dsetrak...@apache.org
> >
> wrote:
>
> > On Wed, Feb 15, 2017 at 4:28 AM, Vladimir Ozerov <voze...@gridgain.com>
> > wrote:
> >
> > > 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.
> > >
> > >
> > Vladimir, how will it work from the DDL perspective. Let's say whenever
> > user wants to create a table in Ignite?
> >
>
