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

[Emmanuel Bernard]

If you really want to split the query part out of the Cache API
cache
.specialize
(QueryableCache
.class).createQuery(luceneQuery).setMaxResults(20).getResultList();

It's still 2 classes less a user needs to learn and remember to simply  
do a query.


On  Jul 3, 2009, at 12:40, Galder Zamarreno wrote:

>
>
> On 07/02/2009 07:34 PM, Galder Zamarreno wrote:
>>
>>
>> On 07/02/2009 07:12 PM, Emmanuel Bernard wrote:
>>> doesn't work, to execute the query, you need to associate it with a
>>> cache instance
>>
>> In that case, cache.createQuery() makes more sense.
>
> Actually, why not this?
>
> Cache cache = new DefaultCacheManager().getCache();
> Query query = new  
> DefaultQueryFactory(cache).getQuery().setMaxResults(20);
> List<Item> results = query.getResultList();
>
> If you extend Cache, let's call it, QueryableCache you're gonna need  
> something that creates that type of cache:
>
> QueryableCache cache = new QueryableCacheManager().getCache();
> Query query = cache.createQuery().setMaxResults(20);
> List<Item> results = query.getResultList();
>
> If in the future we're planning to offer the creation of different  
> types of queries, I'd favor 1st option. Otherwise, 2nd option.
>
>>
>>>
>>> On Jul 2, 2009, at 18:48, Galder Zamarreno wrote:
>>>
>>>>
>>>>
>>>> On 07/02/2009 10:15 AM, Emmanuel Bernard wrote:
>>>>>
>>>>> On Jul 1, 2009, at 10:05, Galder Zamarreno wrote:
>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> Well except that your API will be just verbose and complex to use.
>>>>> What's better?
>>>>>
>>>>> List<Item> results = cache.createQuery(luceneQuery,
>>>>> Item.class).setMaxResults(20).getResultList();
>>>>> or
>>>>> Query q =  
>>>>> cache.getCacheManager().getQueryFactory().create(luceneQuery,
>>>>> Item.class)..setMaxResults(20);
>>>>> List<Item> results = cache.query(q);
>>>>>
>>>>> in other words, who cares if it's a factory, a factory factory  
>>>>> or an
>>>>> abstract factory factory factory. People just want to create a  
>>>>> query
>>>>> and
>>>>> get the result list.
>>>>
>>>> I don't see why you need to extend cache to create a query. I  
>>>> said I
>>>> wasn't sure whether cache needed a query method. Assuming that it
>>>> doesn't needed, Here's how it looks cleaner to me:
>>>>
>>>> Cache cache = new DefaultCacheManager().getCache();
>>>> Query query = new  
>>>> DefaultQueryFactory().getQuery().setMaxResults(20);
>>>> List<Item> results = query.getResultList();
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>
>>
>
> -- 
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache