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
