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 <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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev