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 <voze...@gridgain.com> 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 <dsetrak...@apache.org > > > 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 <voze...@gridgain.com> > > 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. > > > > > >