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

[Emmanuel Bernard]

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?