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