<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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?<br>
<br>
There were some points raised previously like <i>"if you search
for more than one cache transparently, then you probably need to
CRUD for more than one cache transparently as well"</i>. 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. 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.<br>
<br>
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.<br>
<br>
<br>
On 02/18/2014 12:13 AM, Emmanuel Bernard wrote:<br>
</div>
<blockquote
cite="mid:8C0E6B99-E7AC-4D12-BA1D-E7E948750733@hibernate.org"
type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">On 17 févr. 2014, at 18:51, Emmanuel Bernard <a class="moz-txt-link-rfc2396E" href="mailto:emmanuel@hibernate.org"><emmanuel@hibernate.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon 2014-02-17 18:43, Galder Zamarreño wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 05 Feb 2014, at 17:30, Emmanuel Bernard <a class="moz-txt-link-rfc2396E" href="mailto:emmanuel@hibernate.org"><emmanuel@hibernate.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed 2014-02-05 15:53, Mircea Markus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <a class="moz-txt-link-rfc2396E" href="mailto:emmanuel@hibernate.org"><emmanuel@hibernate.org></a> 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.
</pre>
</blockquote>
<pre wrap="">
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 :-)
</pre>
</blockquote>
<pre wrap="">
//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);
</pre>
</blockquote>
<pre wrap="">
Would something like what Paul suggests in <a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/ISPN-3640">https://issues.jboss.org/browse/ISPN-3640</a> 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.
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
</body>
</html>