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(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