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