Folks, thanks for the details. I do acknowledge that this awkward usability
issue is quite annoying and complicates applications' architecture. Problem
with Spring Data
At the moment, I use the workaround mentioned by Alexey Kukushkin. Guess
many of us already use it in productions:
- PersonKey and PersonValue POJOs are used by Ignite repository
abstractions that put or read data to/from Ignite. Those POJOs don't have
repetitive fields.
- Person POJO class is a high-level model that has all the fields of the
table (key + value). PersonKey and PersonValue are converted to a Person
instance by a repository abstraction and that instance is used by other
high-level abstractions of my applications (services, controller, etc.).
Personally, the proposed solution for the problem still sounds complicated
to me. It still requires me, as an application developer, to do some extra
settings in the CacheConfiguration and CREATE TABLE statements.
Let me know what you think about an alternative approach, I've been
contemplating for a while. Those of us who use JPA, Spring Data or
Hibernate frameworks are aware of the Entity abstraction. Which is
basically a POJO class of your business domain model that goes with all the
fields defined in an associated relational/NoSQL table. You use special
annotations to define indexes, primary keys and other relations in that
Entity class. My thinking was to upgrade Ignite cache APIs to the state
when we no longer require to create key POJOs. Instead, you create a single
POJO/Entity, annotate its primary key and pass that object to the cache API
or get it back for read operations.
As an example, let's assume we have this POJO:
@IgnitePrimaryKey(fields = {"id", "passportNo"}, affinityKey="id")
> class Person {
> int id;
> String passportNo;
> String name;
> }
(the primary key fields must always be annotated so that Ignite could
extract those fields internally).
Next, if you want to write an object instance into the cache you do this:
Person personInstance = new Person(5, "23324234", "Thomas");
> ignite.cache("Person").put(personInstance);
To read it back, you just do this
Person personInstance = ignite.cache("Person").get(5, "23324234"); //the
> method can accept an arbitrary number of fields that define a primary key).
The idea is rough and not finalized but I would like us to explore the APIs
evolution in this direction.
-
Denis
On Thu, May 21, 2020 at 7:19 AM Alexey Kukushkin <kukushkinale...@gmail.com>
wrote:
> I vote for implementing this enhancement: having key information separated
> from value means either cluttering domain model with
> KeyValue/CacheEntry-like structures or developing an Ignite data access
> layer to insert key info into domain entity after getting it from Ignite.
>
> Although both the options solve the issue, I think the right approach is to
> address it in Ignite rather than make all the Ignite users repeatedly deal
> with the issue. It is the Ignite which is a re-usable platform and not
> vise-versa.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
