Re: [infinispan-dev] Query module new API and configurations
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/Que...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org