> > I do acknowledge that this awkward usability issue is quite annoying and > complicates applications' architecture. Problem with Spring Data
Sorry, sent the message with the first paragraph left unfinished. "Problem with Spring Data" - just wanted to highlight that the current separation on key and value POJOs leads to other clumsy usability issues: https://issues.apache.org/jira/browse/IGNITE-13028 - Denis On Thu, May 21, 2020 at 12:03 PM Denis Magda <dma...@apache.org> wrote: > 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/ >> >
