We could rely on remote queries?
On 19 November 2013 10:31, Emmanuel Bernard <emman...@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 <emman...@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 <emman...@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@lists.jboss.org >> > >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >>> >> > >>> _______________________________________________ >> > >>> infinispan-dev mailing list >> > >>> infinispan-dev@lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> _______________________________________________ >> > >> infinispan-dev mailing list >> > >> infinispan-dev@lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ >> > > infinispan-dev mailing list >> > > infinispan-dev@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev