If we adapt table-per-cache policy, then table name should be equal to
cache name, especially when table is created via SQL.
For complex types, the type should also be equal to the table name. If the
value type is primitive, then you can still use the table name in SQL and
use the table name as cache name in code.
In my view, the design works. Do you agree?
D.
On Thu, Feb 16, 2017 at 11:58 PM, Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Dima,
>
> Value type name doesn't necessarily maps to table name. For instance, what
> if I have two tables like this? They both have "java.lang.Long" as type
> name.
>
> CREATE table *t1* {
> pk_id BIGINT PRIMARY KEY,
> val BIGINT
> }
>
> CREATE table *t2* {
> pk_id BIGINT PRIMARY KEY,
> val BIGINT
> }
>
> On Fri, Feb 17, 2017 at 12:40 AM, Dmitriy Setrakyan <dsetrak...@apache.org
> >
> wrote:
>
> > 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?
> > > >
> > >
> >
>
