[infinispan-dev] Integration between HotRod and OGM

[Emmanuel Bernard]

We could if someone puts a gun to my head.
But that would be the *only* backend that has to rely on query for its
association.  Hibernate OGM has a strong design bias towards totally
controlling how CRUD is done to guarantee the consistency. If you
introduce a search engine, all bets are off.

On Tue 2013-11-19 10:41, Sanne Grinovero wrote:
> We could rely on remote queries?
> 
> On 19 November 2013 10:31, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > This message was a response to a different email discussing the composite
> > key approach "k1 - a1" "k1 - a2".
> >
> > The actual JIRAs are opened :
> >
> > * https://issues.jboss.org/browse/ISPN-3732
> > * https://issues.jboss.org/browse/ISPN-3733
> >
> > Emmanuel
> >
> > On Tue 2013-11-19 11:22, Emmanuel Bernard wrote:
> >> It's an interesting approach that would work fine-ish for entities
> >> assuming the Hot Rod client is multi threaded and assuming the client
> >> uses Future to parallelize the calls.
> >>
> >> But it won't work for associations as we have them designed today.
> >> Each association - or more precisely the query results to go from an
> >> entity A1 to the list of entities B associated to it - is represented by
> >> an AtomicMap.
> >> Each entry in this map does correspond to an entry in the association.
> >>
> >> While we can "guess" the column names and build from the metadata the
> >> list of composed keys for entities, we cannot do the same for
> >> associations as the key is literally the (composite) id of the
> >> association and we cannot guess that most of the time (we can in very
> >> pathological cases).
> >> We could imagine that we list the association row keys in a special
> >> entry to work around that but this approach is just as problematic and
> >> is conceptually the same.
> >> The only solution would be to lock the whole association for each
> >> operation and I guess impose some versioning / optimistic lock.
> >>
> >> That is not a pattern that scales sufficiently from my experience.
> >> That's the problem with interconnected data :)
> >>
> >> Emmanuel
> >>
> >> On Mon 2013-11-18 23:05, Mircea Markus wrote:
> >> > Neither the grouping API nor the AtomicMap work over hotrod.
> >> > Between the grouping API and AtomicMap, I think the one that would make more sense migrating is the grouping API.
> >> > One way or the other, I think the hotrod protocol would require an enhancement - mind raising a JIRA for that?
> >> > For now I guess you can sacrifice performance and always sending the entire object across on every update instead of only the deltas?
> >> >
> >> > On Nov 18, 2013, at 9:56 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >> >
> >> > > Someone mentioned the grouping API as some sort of alternative to
> >> > > AtomicMap. Maybe we should use that?
> >> > > Note that if we don't have a fine-grained approach we will need to
> >> > > make sure we *copy* the complex data structure upon reads to mimic
> >> > > proper transaction isolation.
> >> > >
> >> > > On Tue 2013-11-12 15:14, Sanne Grinovero wrote:
> >> > >> On 12 November 2013 14:54, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >> > >>> On the transaction side, we can start without them.
> >> > >>
> >> > >> +1 on omitting transactions for now.
> >> > >>
> >> > >> And on the missing AtomicMaps, I hope the Infinispan will want to implement it?
> >> > >> Would be good to eventually converge on similar featuresets on remote
> >> > >> vs embedded APIs.
> >> > >>
> >> > >> I know the embedded version relies on batching/transactions, but I
> >> > >> guess we could obtain a similar effect with some ad-hoc commands in
> >> > >> Hot Rod?
> >> > >>
> >> > >> Sanne
> >> > >>
> >> > >>>
> >> > >>> On Tue 2013-11-12 14:34, Davide D'Alto wrote:
> >> > >>>> Hi,
> >> > >>>> I'm working on the integration between HotRod and OGM.
> >> > >>>>
> >> > >>>> We already have a dialect for Inifinispan and I'm trying to follow the same
> >> > >>>> logic.
> >> > >>>> At the moment I'm having two problems:
> >> > >>>>
> >> > >>>> 1) In the Infinispan dialect we are using the AtomicMap and the
> >> > >>>> AtomicMapLookup but this classes don't work with the RemoteCache. Is there
> >> > >>>> an equivalent for HotRod?
> >> > >>>>
> >> > >>>> 2) As far as I know HotRod does not support transactions. I've found a link
> >> > >>>> to a branch on Mircea repository:
> >> > >>>> https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
> >> > >>>> Is this something I could/should use?
> >> > >>>>
> >> > >>>> Any help is appreciated.
> >> > >>>>
> >> > >>>> Thanks,
> >> > >>>> Davide
> >> > >>>
> >> > >>>> _______________________________________________
> >> > >>>> infinispan-dev mailing list
> >> > >>>> infinispan-dev at lists.jboss.org
> >> > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> infinispan-dev mailing list
> >> > >>> infinispan-dev at lists.jboss.org
> >> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > >> _______________________________________________
> >> > >> infinispan-dev mailing list
> >> > >> infinispan-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > > _______________________________________________
> >> > > infinispan-dev mailing list
> >> > > infinispan-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> >
> >> > Cheers,
> >> > --
> >> > Mircea Markus
> >> > Infinispan lead (www.infinispan.org)
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > infinispan-dev mailing list
> >> > infinispan-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev