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

Tue Apr 5 06:03:47 EDT 2011

See comments below:

On Apr 4, 2011, at 7:24 PM, Sanne Grinovero wrote:

> thanks for the quick and comprehensive feedback.
> diving inline:
> 
> 2011/4/4 Emmanuel Bernard <emmanuel at hibernate.org>:
>> </snip>
>> 
>> - I'm not a big fan of the constructor approach to get QueryFactory for various reasons (including the fact that it forces a concrete type and no interfaces) but it seems to be an ISPN-wide design decision
>> That's definitely something that could be improved in a Seam Infinispan module.
> 
> I knew you where going to say that :) but yes this seems to be more
> Infinispan-style.
> I've considered something like a Search.getQueryFactory(Cache c) .. WDYT?
> This wouldn't return a "FullTextCache" but the manager, I see no
> reason to delegate a cache like we do with a o.h.Session.

Is this Hibernate Search API you're talking about?

> 
>> - I'd rename QueryFactory to something else as conceptually it's more an entry point to anything related to Hibernate Search, potentially indexing, stats etc: maybe SearchManager, SearchProvider, GridSearcher, TheGridReaper?
> right!
> which one? I like the first three.

I'd go with SearchManager to follow other naming patterns such as CacheManager.

> 
>> 
>> - is there an easy metaconfig to ask ISPN to store the HSearch indexes in ISPN :)
> No, but agree that would be awesome. would require changes though in
> all involved projects:
> 1) H.S. would bee to be able to start on a DirectoryProvider instance we pass in
> 2) Infinispan Directory module (the submodule of H.S.) would need to
> be able to reconfigure an existing cachemanager configuration during
> the startup
> 3) Infinispan Core needs to be adapted for the additional configuration fields
> currently it's not that hard, just a single property:
> 
> <indexing enabled="true" indexLocalOnly="true">
>   <properties>
>      <property
> name="hibernate.search.default.directory_provider" value="infinispan" />
>      </properties>
> </indexing>
> 
> downside is that it will start a second cachemanager with a second
> JGroups channel, instead of reusing the same.

JGroupsChannelLookup is there to enable multiple cache managers to share the same CacheManager. We don't have an impl for standalone cases but that's what AS uses to feed in the JGroups channel to the various cache managers.

> 
>> 
>> - you can't do cross Cache queries today. Is that expected? for me CacheManager.getGridSearcher almost makes sense.
> Very interesting concept. I'll see how that fits in the code; I can't
> add methods to the CacheManager itself, but maybe I can make sure that
> interceptors registered on different caches share the same
> MutableSearchFactory.
> 
>> 
>> - for the discovery issue, option 2 and 3 are the only two viable to me
> I'll work towards 2 first, looks simpler. BTW 3 requires the user to
> configure a permanent cachestore, or at the bare minimum to be
> dist/repl.
> 
> Cheers,
> Sanne
> 
>> On 4 avr. 2011, at 18:23, Sanne Grinovero wrote:
>> 
>>> Infinispan 4.0 contained an integration with Hibernate Search to index
>>> stored POJOs using the well-known Hibernate Search annotations; but
>>> the configuration was tricky and the API quite limited.
>>> With the latest changes in H.Search, we could now make a better integration.
>>> 
>>> Quick recap on configuration/usage on Infinispan 4:
>>> 1) indexing must be enabled in Infinispan configuration
>>> 2) a queryHelper class must be started and pointed to known types to
>>> be indexed, passing it HS configuration properties
>>> - this would start a Hibernate Search engine
>>> - modifications done on the grid before the queryHelper was started
>>> are ignored by the indexing engine
>>> - list of "known entities" could not be changed
>>> 3) use a queryFactory to create queries, which needs to be hooked up
>>> the previously started queryHelper
>>> - the query options where a bit limited
>>> 
>>> What's coming in Infinispan 5:
>>> 1) indexing is still be enabled in Infinispan configuration
>>>  - Hibernate Search configuration properties are embedded in the
>>> Infinispan configuration
>>> 
>>> <infinispan>
>>>   <default>
>>>      <indexing enabled="true" indexLocalOnly="true">
>>>         <properties>
>>>            <property
>>> name="hibernate.search.default.directory_provider" value="ram" />
>>>         </properties>
>>>      </indexing>
>>>   </default>
>>> </infinispan>
>>> 
>>> 
>>> 2) no queryHelper is needed
>>> - lifecycle of the indexing engine is managed by Infinispan
>>> - new entity types are autodiscovered
>>>   (each time a previously unseen class is put/removed it's annotation
>>> scanned and HS is potentially reconfigured)
>>> 
>>> 3) you still use a QueryFactory, like in the examples linked below
>>> - exposes all features of Hibernate Search query builder DSL
>>> - Faceting
>>> - projections, etc..
>>> 
>>> API, most significant classes:
>>> https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42da3e8e565/query/src/main/java/org/infinispan/query/CacheQuery.java
>>> https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42da3e8e565/query/src/main/java/org/infinispan/query/QueryFactory.java
>>> 
>>> Two usage examples:
>>> https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42da3e8e565/query/src/test/java/org/infinispan/query/queries/faceting/SimpleFacetingTest.java
>>> https://github.com/Sanne/infinispan/blob/eafe084a2ffa7e539768c838334ad42da3e8e565/query/src/test/java/org/infinispan/query/indexedembedded/CollectionsIndexingTest.java
>>> 
>>> 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?
>>> - explicitly list indexed entities in Infinispan configuration?
>>> - a metadata cache maintaining a distributed&stored copy of known types
>>> - search for types in the index :)  would be nice, but the current
>>> design in Search mandates to know the entities first to know how the
>>> indexes are named. without name I can't open the index, but maybe we
>>> could have the user specify the index names instead of all entity
>>> classtypes.
>>> 
>>> Feedback on the API is more urgent than to solve this, so it could
>>> make it for Infinispan 5 Beta1.
>>> 
>>> Cheers,
>>> Sanne
>> 
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache