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.

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

Thanks guys, 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

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

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

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.

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

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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev