> > However, could you please elaborate on the relation between Ignite and ORM? > Is there a use case for Hibernate running on top of Ignite (I haven't seen > one so far)? If so, what is missing exactly on the Ignite side to support > this? In my understanding, all you need is SQL API which we already have. > Am I missing something?
Good point, yes, if all the ORM integrations use Ignite SQL APIs internally, then they can easily translate an Entity object into an INSERT/UPDATE statement that lists all the object's fields. Luckily, our Spring Data integration is already based on the Ignite SQL APIs and needs to be improved once the schema-first approach is supported. That would solve a ton of usability issues. I would revise the Hibernate integration as well during the Ignite 3.0 dev phase. Can't say if it's used a lot but Spring Data is getting traction for sure. @Michael Pollind, I'll loop you in as long as you've started working on the Ignite support for Micornaut Data <https://micronaut-projects.github.io/micronaut-data/latest/guide/> and came across some challenges. Just watch this discussion. That's what is coming in Ignite 3.0. - Denis On Mon, Aug 31, 2020 at 5:11 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Denis, > > Generally speaking, I believe that the schema-first approach natively > addresses the issue if duplicate fields in key and value objects, because > schema will be created for a cache, not for an object, as it happens now. > Basically, the schema will define whether there is a primary key or not, > and which fields are included in case there is one. Any API that we would > have must be compliant with this, so it becomes fairly easy to work with > data as with a set of records, rather than key-value pairs. > > However, could you please elaborate on the relation between Ignite and ORM? > Is there a use case for Hibernate running on top of Ignite (I haven't seen > one so far)? If so, what is missing exactly on the Ignite side to support > this? In my understanding, all you need is SQL API which we already have. > Am I missing something? > > -Val > > On Mon, Aug 31, 2020 at 2:08 PM Denis Magda <dma...@apache.org> wrote: > > > Val, > > > > I would propose adding another point to the motivations list which is > > related to the ORM frameworks such as Spring Data, Hibernate, Micronaut > and > > many others. > > > > Presently, the storage engine requires to distinguish key objects from > the > > value ones that complicate the usage of Ignite with those ORM frameworks > > (especially if a key object comprises several fields). More on this can > be > > found here: > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Key-and-Value-fields-with-same-name-and-SQL-DML-td47557.html > > > > It will be nice if the new schema-first approach allows us to work with a > > single entity object when it comes to the ORMs. With no need to split the > > entity into a key and value. Just want to be sure that the Ignite 3.0 has > > all the essential public APIs that would support the single-entity based > > approach. > > > > What do you think? > > > > - > > Denis > > > > > > On Fri, Aug 28, 2020 at 3:50 PM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Igniters, > > > > > > One of the big changes proposed for Ignite 3.0 is the so-called > > > "schema-first approach". To add more clarity, I've started writing the > > IEP > > > for this change: > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach > > > > > > Please take a look and let me know if there are any immediate thoughts, > > > suggestions, or objections. > > > > > > -Val > > > > > >
