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

Manik Surtani manik at jboss.org
Wed Apr 20 13:51:39 EDT 2011


On 4 Apr 2011, at 18:24, Sanne Grinovero wrote:

>> 
>> - getBasicQuery methods are deprecated. That's from the previous design right? Was it a tech preview or was it named as full fledged API?
>> In the former case I'd get rid of them.
> 
> Yes that was a tech preview, I'll remove them, but maybe better keep
> them for a single release?
> There's a grails plugin which exposes these methods.

Mark them as deprecated and ping the maintainer of the grails plugin?

> 
>> - 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?

+1.

> 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.
> 
>> - 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.

SearchManager would be inline with other Infinispan components.  QueryManager perhaps?

>> - 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" />

Could this be the default, if no other directory provider is specified?

>      </properties>
> </indexing>
> 
> downside is that it will start a second cachemanager with a second
> JGroups channel, instead of reusing the same.

Could it not use the same cache manager?

> 
>> 
>> - 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.

Perhaps something for SearchManager/QueryManager... 

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110420/06fa46b0/attachment-0001.html 


More information about the infinispan-dev mailing list