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

2011/4/5 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > > 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.