[infinispan-dev] Query module new API and configurations

[Galder Zamarreno]

On 08/25/2009 11:33 AM, Manik Surtani wrote:
> 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.

Slight tangent but related to the issue raised by Navin is the issue I 
had with modules other than core, or users, defining their own 
@Marshallable instances.

Currently, for modules such as tree that have an Externalizer for Fqn, 
I've hardcoded the mapping between the class and its marshallable in 
core module.

So, any work where modules can inject configuration such as extra 
interceptors or marshallable mappings would help.

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