[infinispan-dev] Query module new API and configurations

[Manik Surtani]

On 25 Aug 2009, at 10:13, Navin Surtani wrote:

> Hey guys,
>
> Was speaking with Manik the other day and we were just talking about
> how we could work in some of the new API into the query module.
>
> What I was thinking to do was something like this: -
>
> CacheQuery cq = new QueryFactory(cache).getQuery("fieldName",
> "stuffToSearchFor");

Looks good.  But I think we should also support Lucene queries  
directly, as they provide a richer set of searchable terms and  
constraints.  Or perhaps impls like BooleanQuery to combine queries.

E.g.:

	Query luceneQuery = createComplexLuceneQuery();
	CacheQuery cq = new QueryFactory(cache).getQuery(luceneQuery);

See:

	http://lucene.apache.org/java/2_4_1/api/core/org/apache/lucene/search/Query.html

> This way, internally we can do all the dirty work of creating lucene
> queries, using a query parser etc etc. Which is a major clean-up from
> the old JBCS API where you'd need to create it yourself.
>
> The other issue we discussed was setting up searchable configurations.
> Vladimir, I believe you're the guy who can help us a bit on this?
> Essentially, what Manik suggested was to put in a configuration option
> (eg: - 'searchable = true') and then from there internal cache code
> should know how to deal with adding in the SearchableInterceptor.
> Maybe an XML parser does this? Feel free to throw something at me if
> I'm wrong here.
>
> The slightly complex part here is that the Searchable Interceptor sits
> in the query module. So if you're only using the core module it also
> needs to be able to ignore the query configuration if it doesn't have
> the dependency or if the user doesn't want to use the module etc etc.

Yeah this needs thought, and is a more generic question than something  
specific to querying.  Essentially, how does module X get its  
configuration from XML, where the XML parsing and schema logic is in  
the core module? Vladimir, any thoughts?

Perhaps what we need is some form of module bootstrap, or a callback  
of sorts?  I suppose there are 2 parts to this:  the first being a  
bean to parse and hold configuration specifics, so that the parser can  
instantiate this bean, e.g., QueryConfiguration, and then an actual  
bootstrap to bind module-specific components to the ComponentRegistry  
so it participates in various lifecycle phases of the cache.

>
> WDYT?
>
> Navin Surtani
>
> Intern Infinispan
> Intern JBoss Cache Searchable
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org