DML usability: routing single column to several object fields

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DML usability: routing single column to several object fields

Vladimir Ozerov
Igniters,

Consider the following pattern which is typically used by users when
working through cache API and quering data through SQL at the same time:

class Person {
    @QuerySqlField
    long id;

    @QuerySqlField
    String name;
}

cache.put(*id*, new Person(*id*, name));

SELECT *id*, name FROM person;

Notice that ID is stored twice per cache record - once for key, and once
for value. This pattern is very convenient for users - loose some little
space due to duplication on the one hand, but have self-contained value
with all necessary data on the other. In fact virtually all production
systems I saw followed this approach and had some minor duplication.

It seems this approach doesn't work well with DML and upcoming DDL. When
executing INSERT INTO Person VALUES (:id, :name), I specify two attributes
which must update three cache fields.

In order to preserve usability of native cache API when DML is involved, we
need ability to map certain attribute to several Object properties.
Probably this can be achieved with additional field property which defines
that it belongs to a group mapped to an attribute. May be existing aliases
could be used for this.

Or we can ignore the problem sacrificing cache API usability a bit in case
of DML/DDL

Any ideas on whether we need it, and how to design public API?

Vladimir.
Reply | Threaded
Open this post in threaded view
|

Re: DML usability: routing single column to several object fields

dsetrakyan
Vladimir,

When a table is created, user should specify the "primary key". We can
extract this field and use it as the key into the BTree index. This way it
will fit into the current design. Am I wrong?

D.

On Thu, Feb 16, 2017 at 4:33 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> Consider the following pattern which is typically used by users when
> working through cache API and quering data through SQL at the same time:
>
> class Person {
>     @QuerySqlField
>     long id;
>
>     @QuerySqlField
>     String name;
> }
>
> cache.put(*id*, new Person(*id*, name));
>
> SELECT *id*, name FROM person;
>
> Notice that ID is stored twice per cache record - once for key, and once
> for value. This pattern is very convenient for users - loose some little
> space due to duplication on the one hand, but have self-contained value
> with all necessary data on the other. In fact virtually all production
> systems I saw followed this approach and had some minor duplication.
>
> It seems this approach doesn't work well with DML and upcoming DDL. When
> executing INSERT INTO Person VALUES (:id, :name), I specify two attributes
> which must update three cache fields.
>
> In order to preserve usability of native cache API when DML is involved, we
> need ability to map certain attribute to several Object properties.
> Probably this can be achieved with additional field property which defines
> that it belongs to a group mapped to an attribute. May be existing aliases
> could be used for this.
>
> Or we can ignore the problem sacrificing cache API usability a bit in case
> of DML/DDL
>
> Any ideas on whether we need it, and how to design public API?
>
> Vladimir.
>
Reply | Threaded
Open this post in threaded view
|

Re: DML usability: routing single column to several object fields

Vladimir Ozerov
Dima,

I am not sure we are talking about the same thing. My point is that
currently single value is often mapped to several values in cache key-value
pair. This is done for usability reasons, and the question is how to
continue supporting this approach with DML. Let me show the problem again,
consider the following value class:

This is how users often work with Ignite:

class Person {
    long id;
    String name;
}

IgniteCache<Long, Person> cache = ...;

Person getById(long id) {
    return cache.get(id);
}

DML doesn't support this approach at the moment, because we cannot map
single attribute from DML statement to multiple destinations in key-value
pair (_key + _val.Person.id). For this reason users will have to redefine
their schema and do the following:

IgniteCache<Long, String> cache = ...;

Person getById(long id) {
    return new Person(id, cache.get(id));
}

Only [DML + cache API] interaction is affected. No problems with [DML +
SELECT] usages.


On Thu, Feb 16, 2017 at 11:27 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Vladimir,
>
> When a table is created, user should specify the "primary key". We can
> extract this field and use it as the key into the BTree index. This way it
> will fit into the current design. Am I wrong?
>
> D.
>
> On Thu, Feb 16, 2017 at 4:33 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > Consider the following pattern which is typically used by users when
> > working through cache API and quering data through SQL at the same time:
> >
> > class Person {
> >     @QuerySqlField
> >     long id;
> >
> >     @QuerySqlField
> >     String name;
> > }
> >
> > cache.put(*id*, new Person(*id*, name));
> >
> > SELECT *id*, name FROM person;
> >
> > Notice that ID is stored twice per cache record - once for key, and once
> > for value. This pattern is very convenient for users - loose some little
> > space due to duplication on the one hand, but have self-contained value
> > with all necessary data on the other. In fact virtually all production
> > systems I saw followed this approach and had some minor duplication.
> >
> > It seems this approach doesn't work well with DML and upcoming DDL. When
> > executing INSERT INTO Person VALUES (:id, :name), I specify two
> attributes
> > which must update three cache fields.
> >
> > In order to preserve usability of native cache API when DML is involved,
> we
> > need ability to map certain attribute to several Object properties.
> > Probably this can be achieved with additional field property which
> defines
> > that it belongs to a group mapped to an attribute. May be existing
> aliases
> > could be used for this.
> >
> > Or we can ignore the problem sacrificing cache API usability a bit in
> case
> > of DML/DDL
> >
> > Any ideas on whether we need it, and how to design public API?
> >
> > Vladimir.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: DML usability: routing single column to several object fields

dsetrakyan
Vladimir,

Still not clear. Why not create a proper mapping of a table attribute to a
key? If we don't support it today, do you think it will be feasible to add
such support?

D.

On Fri, Feb 17, 2017 at 12:25 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Dima,
>
> I am not sure we are talking about the same thing. My point is that
> currently single value is often mapped to several values in cache key-value
> pair. This is done for usability reasons, and the question is how to
> continue supporting this approach with DML. Let me show the problem again,
> consider the following value class:
>
> This is how users often work with Ignite:
>
> class Person {
>     long id;
>     String name;
> }
>
> IgniteCache<Long, Person> cache = ...;
>
> Person getById(long id) {
>     return cache.get(id);
> }
>
> DML doesn't support this approach at the moment, because we cannot map
> single attribute from DML statement to multiple destinations in key-value
> pair (_key + _val.Person.id). For this reason users will have to redefine
> their schema and do the following:
>
> IgniteCache<Long, String> cache = ...;
>
> Person getById(long id) {
>     return new Person(id, cache.get(id));
> }
>
> Only [DML + cache API] interaction is affected. No problems with [DML +
> SELECT] usages.
>
>
> On Thu, Feb 16, 2017 at 11:27 PM, Dmitriy Setrakyan <[hidden email]
> >
> wrote:
>
> > Vladimir,
> >
> > When a table is created, user should specify the "primary key". We can
> > extract this field and use it as the key into the BTree index. This way
> it
> > will fit into the current design. Am I wrong?
> >
> > D.
> >
> > On Thu, Feb 16, 2017 at 4:33 AM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Igniters,
> > >
> > > Consider the following pattern which is typically used by users when
> > > working through cache API and quering data through SQL at the same
> time:
> > >
> > > class Person {
> > >     @QuerySqlField
> > >     long id;
> > >
> > >     @QuerySqlField
> > >     String name;
> > > }
> > >
> > > cache.put(*id*, new Person(*id*, name));
> > >
> > > SELECT *id*, name FROM person;
> > >
> > > Notice that ID is stored twice per cache record - once for key, and
> once
> > > for value. This pattern is very convenient for users - loose some
> little
> > > space due to duplication on the one hand, but have self-contained value
> > > with all necessary data on the other. In fact virtually all production
> > > systems I saw followed this approach and had some minor duplication.
> > >
> > > It seems this approach doesn't work well with DML and upcoming DDL.
> When
> > > executing INSERT INTO Person VALUES (:id, :name), I specify two
> > attributes
> > > which must update three cache fields.
> > >
> > > In order to preserve usability of native cache API when DML is
> involved,
> > we
> > > need ability to map certain attribute to several Object properties.
> > > Probably this can be achieved with additional field property which
> > defines
> > > that it belongs to a group mapped to an attribute. May be existing
> > aliases
> > > could be used for this.
> > >
> > > Or we can ignore the problem sacrificing cache API usability a bit in
> > case
> > > of DML/DDL
> > >
> > > Any ideas on whether we need it, and how to design public API?
> > >
> > > Vladimir.
> > >
> >
>