On 19 November 2013 12:56, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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.
I think it's something to consider as that's what Hibernate ORM does
(when targeting relational databases), so we ease the mismatch.
The issues you've opened are probably preferable, but remote queries
are the only viable option I'm seeing which is available now.
Sanne
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(a)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(a)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(a)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(a)lists.jboss.org
> >> > >>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> infinispan-dev mailing list
> >> > >>> infinispan-dev(a)lists.jboss.org
> >> > >>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > >> _______________________________________________
> >> > >> infinispan-dev mailing list
> >> > >> infinispan-dev(a)lists.jboss.org
> >> > >>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> > > _______________________________________________
> >> > > infinispan-dev mailing list
> >> > > infinispan-dev(a)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(a)lists.jboss.org
> >> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev