[infinispan-dev] new Infinispan Query API - ISPN-194

[Israel Lacerra]

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 <emmanuel at hibernate.org>wrote:

>
> On 5 avr. 2011, at 13:38, Sanne Grinovero wrote:
>
> > 2011/4/5 Emmanuel Bernard <emmanuel at hibernate.org>:
> >>
> >> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110409/8bf69ce8/attachment.html