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
