To make a LazyIterator for ISPN-200 (<a href="https://issues.jboss.org/browse/ISPN-200">https://issues.jboss.org/browse/ISPN-200</a>) I was starting a query in each node and then merging the results (TopDocs) in the requester node...<br>

<br><div class="gmail_quote">On Sun, Apr 10, 2011 at 6:10 AM, Emmanuel Bernard <span dir="ltr">&lt;<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word">Why do you need TopDocs? What&#39;s the use case?<div><div></div><div class="h5"><div><br><div><div>On 10 avr. 2011, at 03:42, Israel Lacerra wrote:</div><br><blockquote type="cite">Guys,<br>

<br>Do you think we can have a getQueryHits() on HSQueryImpl? To do ISPN-200 I was using the TopDocs and now, with Infinispan using HSQueryImpl, TopDocs is a little more hided....<br><br>Anyway, take this just as a &quot;suggestion&quot;. I can get the TopDocs in another less fashion way :).<br>



<br>cheers<br><br>Israel<br><br><div class="gmail_quote">On Tue, Apr 5, 2011 at 9:23 AM, Emmanuel Bernard <span dir="ltr">&lt;<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div></div><div><br>
On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:<br>
<br>
&gt; 2011/4/5 Emmanuel Bernard &lt;<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt; On 5 avr. 2011, at 12:20, Galder Zamarreño wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Apr 4, 2011, at 6:23 PM, Sanne Grinovero wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &lt;/snip&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; there&#39;s one catch:<br>
&gt;&gt;&gt;&gt; when searching for a class type, it will only include results from<br>
&gt;&gt;&gt;&gt; known subtypes. The targeted type is automatically added to the known<br>
&gt;&gt;&gt;&gt; classes, but eventually existing subtypes are not discovered.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Bringing this issue to an extreme, if the query is not targeting any<br>
&gt;&gt;&gt;&gt; type, and no indexed types where added to the grid (even if some exist<br>
&gt;&gt;&gt;&gt; already as they might have been inserted by other JVMs or previous<br>
&gt;&gt;&gt;&gt; runs), all queries will return no results.<br>
&gt;&gt;&gt;&gt; How to solve this?<br>
&gt;&gt;&gt;&gt; - class scanning?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Nope, too expensive.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - explicitly list indexed entities in Infinispan configuration?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; No<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - a metadata cache maintaining a distributed&amp;stored copy of known types<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; That sounds more appealing. It could be a good middle ground until Search can search for types.<br>
&gt;&gt;<br>
&gt;&gt; Do you have any specific idea in mind?<br>
&gt;&gt;<br>
&gt;&gt; To magically find types:<br>
&gt;&gt;  - we scan every file system, databases, caches available to the app and look for Lucene metadata =&gt; unrealistic<br>
&gt;&gt;  - there is some kind of convention on where the indexes are and we do index scanning at startup =&gt; scanning are very likely to be slower that class scanning (potential remote access, bigger dataset etc)<br>
&gt;&gt;  - we enforce one or a fixed number of Lucene indexes for all data in Infinispan =&gt; not sure that&#39;s a good idea but this can be explored<br>
&gt;&gt;  - we somehow ask the framework using HSearch to fill up classes<br>
&gt;&gt;<br>
&gt;&gt; other approaches?<br>
&gt;<br>
&gt; why was class scanning discarded in the first answer? as H. Search can<br>
&gt; auto-discover classes by working on top of JPA entity autodiscovery, I<br>
&gt; guess that each application node could look into it&#39;s own known<br>
&gt; classpath.<br>
&gt; After all if some type is not visible to him as it was added from<br>
&gt; another node from a different app, he won&#39;t be able to return<br>
&gt; instances of it either.<br>
&gt; We could face the opposite problem of building metadata of classes<br>
&gt; people doesn&#39;t mean to index in this cache.<br>
<br>
</div></div>Right. scanning (class or index) will be a bit aggressive and could build unneeded metadata (or even worse, return unexpected classes).<br>
<div><div></div><div>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br>
</blockquote></div><br></div></div></div></div></blockquote></div><br>