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?
>

Reply via email to