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

Sanne Grinovero sanne.grinovero at gmail.com
Tue Apr 5 07:38:20 EDT 2011


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.



More information about the infinispan-dev mailing list