On Feb 18, 2014, at 12:02 PM, Adrian Nistor <anis...@redhat.com> wrote:
> Well, OGM and Infinispan are different species :) So, Infinispan being what
> it is today - a non-homogenous, schema-less KV store, without support for
> entity associations (except embedding) - which simplifies the whole thing a
> lot, should we or should we not provide transparent cross-cacheManager search
> capabilities, in this exact context? Vote?
TBH I think users should push us for this if they need it. -1 to do it right
now.
>
> There were some points raised previously like "if you search for more than
> one cache transparently, then you probably need to CRUD for more than one
> cache transparently as well". In the SQL world you would also probably CRUD
> against a table or set of tables and then query against a view - a bit like
> what we're doing here.
> I don't see any problem with this in principle. There is however something
> currently missing in the query result set API - it currently does not provide
> you the keys of the matching entities.
would be nice to have an option for that, indeed.
> People work around this by storing the key in the entity. Now with the
> addition of the cross-cacheManager search we'll probably need to fix the
> result api and also provide a reference to the cache (or just the name?)
> where the entity is stored.
>
> The (enforced) one entity type per cache rule is not conceptually or
> technically required for implementing this, so I won't start raving against
> it :) Sane users should apply it however.
>
>
> On 02/18/2014 12:13 AM, Emmanuel Bernard wrote:
>> By the way, Mircea, Sanne and I had quite a long discussion about this one
>> and the idea of one cache per entity. It turns out that the right (as in
>> easy) solution does involve a higher level programming model like OGM
>> provides. You can simulate it yourself using the Infinispan APIs but it is
>> just cumbersome.
>>
>>
>>> On 17 févr. 2014, at 18:51, Emmanuel Bernard <emman...@hibernate.org>
>>> wrote:
>>>
>>>
>>>> On Mon 2014-02-17 18:43, Galder Zamarreño wrote:
>>>>
>>>>
>>>>> On 05 Feb 2014, at 17:30, Emmanuel Bernard <emman...@hibernate.org>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> On Wed 2014-02-05 15:53, Mircea Markus wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <emman...@hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Sure searching for any cache is useful. What I was advocating is that
>>>>>>> if you search for more than one cache transparently, then you probably
>>>>>>> need to CRUD for more than one cache transparently as well. And this is
>>>>>>> not being discussed.
>>>>>>>
>>>>>> Not sure what you mean by CRUD over multiple caches? ATM one can run a
>>>>>> TX over multiple caches, but I think there's something else you have in
>>>>>> mind :-)
>>>>>>
>>>>>
>>>>> //some unified query giving me entries pointing by fk copy to bar and
>>>>> //buz objects. So I need to manually load these references.
>>>>>
>>>>> //happy emmanuel
>>>>> Cache unifiedCache = cacheManager.getMotherOfAllCaches();
>>>>> Bar bar = unifiedCache.get(foo);
>>>>> Buz buz = unifiedCache.get(baz);
>>>>>
>>>>> //not so happy emmanuel
>>>>> Cache fooCache = cacheManager.getCache("foo");
>>>>> Bar bar = fooCache.get(foo);
>>>>> Cache bazCache = cacheManager.getCache("baz");
>>>>> Buz buz = bazCache.put(baz);
>>>>>
>>>> Would something like what Paul suggests in
>>>> https://issues.jboss.org/browse/ISPN-3640
>>>> help you better? IOW, have a single cache, and then have a filtered view
>>>> for Bar or Buz types? Not sure I understand the differences in your code
>>>> changes in terms of what makes you happy vs not.
>>>>
>>> Not really.
>>> What makes me unhappy is to have to keep in my app all the
>>> references to these specific cache store instances. The filtering
>>> approach only moves the problem.
>>> _______________________________________________
>>> 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
