[infinispan-dev] [ISPN-32] API changes for query module

[Mircea Markus]

Galder Zamarreno wrote:
>
>
> On 06/30/2009 12:42 PM, Navin Surtani wrote:
>> Heya guys,
>>
>> I'm just getting going with the query module for infinispan (ISPN-32 in
>> branches) and I just wanted to send around a couple of emails so I could
>> get an idea on some changes that I was thinking about making.
>>
>> 1 - query module: -
>>
>> I decided this would be a better name than 'searchable' from JBCS
>> because I think that this would be a better name, and also JBCS never
>> really took off imo so I don't really want to stick with the old name.
>
> No probs on my side :)
same here :)
>
>>
>> 2 - createQuery(): -
>>
>> This was JBCS's only extra API method on the cache interface (or
>> SearchableCache) and I was thinking that maybe this is quite a long
>> method name - given that the cache has put(), get() etc ... I was
>> thinking of using query() but given that Lucene and Hibernate Search
>> both have Query classes that users deal with I'm wondering if there's
>> too much use of the word query. On the flipside, those are classes and
>> not API methods so it might work.
>>
>> I'm not too worried about continuing on with createQuery() but think it
>> might work.
>>
>> Another alternative would be search() but I'm not too convinced by that.
>>
>> 3 - SearchableCache: -
>>
>> Should the name of this class be changed? I don't think so but if anyone
>> has any ideas ...
>
> Here's my point of view:
>
> createQuery() looks to me like factory method and so I think it would 
> suit more a factory interface, i.e. QueryFactory? rather than in an 
> extension of Cache.
>
> IMO, extending Cache interface would make sense if you're gonna add an 
> operation against the searchable or queryable cache itself, such 
> query(). But this method kind of implies that you actually execute the 
> query against the cache, so you'd imagine taking a CacheQuery as 
> parameter. Bearing in mind my limited knowledge of how users use JBC 
> Searchable, I dunno if having such method makes sense or not. If it 
> does not, not a problem. Stick with a QueryFactory interface that has 
> a create() method that returns Query (or CacheQuery) and that's it.
>
As Galder mentioned, there is a semantic difference between "query" and 
"createQuery", and this method actually creates a query rather than 
executing one. hence, I would rather go for "createQuery"
>
>>
>> Thanks guys,
>>
>> 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
>