[hibernate-dev] JBoss Cache Searchable interfaces

[Emmanuel Bernard]

--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com 
  | http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)

On  Jun 24, 2008, at 13:15, Manik Surtani wrote:

> Hi guys - a few comments on the public interfaces of SearchableCache -
>
> 1) IMO, I think that the SearchableCache.createQuery() method should  
> *not* return a FullTextQuery, but instead a JBCS-specific CacheQuery  
> interface with a subset of the methods in FullTextQuery.

+1


>
> I think the only methods in FullTextQuery that are relevant and that  
> should be carried across to CacheQuery are:
>
> * list()
+1
> * iterator();
don't think it's that useful in practice, scroll is probably more  
practical as it lazily loads Lucene data (contrary to iterator)
> * setFirstResult(int i);
+1
> * setMaxResults(int i);
+1
> * setFetchSize(int i);
+1
> * getResultSize();
+1
> * setSort();
+1
scroll()
setFilter, enableFullTextFilter, disableFullTextFilter is a total must  
have to do temporal patterns, category filter and so on. This is  
Lucene filters, not Hibernate Core filters.
setProjection() you need projection for metadata setResultTransformer  
is a consequence. It probably makes sense to project regular  
properties too (memory wise for sure, needs probably more testing  
speed wise)
uniqueResult() is quite nice


>
> I think all of the rest - such as filters, criteria and projections  
> - are irrelevant to a query on a cache.  WDYT?  Emmanuel?

they are relevant, see above

>
> 2) Also, rather than implement FullTextQuery.scroll() to return a  
> ScrollableResults instance, I'd rather that iterator() returns an  
> instance of a new interface, QueryResultsIterator, which extends  
> j.u.ListIterator.  This gives us the ability to scroll back and  
> forth over a result set, and we could add additional methods to jump  
> to a specific point in the result set and helpers such as isLast(),  
> isFirst(), isBeforeLast(), isAfterFirst(), first(), last(),  
> afterFirst(), beforeLast().

That's the point of Scroll, but you can rename it if you want. What's  
important is that you need a .close() method to release the lucene  
resources. also scroll() could return null if the object is not found  
in the cache (inconsistency), iterate() will just ignore the entry.

>
> I think that any benefit of a scrollable result set window  
> preventing loading unnecessary objects from a DB are lost when your  
> backing store is a cache and the objects are in memory anyway.  And  
> besides, any further optimisations can be in the iterator  
> implementation, such as just maintaining a list of CachedEntityIds  
> (a composite of Fqn and key) and fetching the objects from the cache  
> lazily, as required.

iterate() lazily load object from the DB but eagerly loads Lucene stuffs
scroll() lazily load everything but need a .close()

>
> Also, with the above, 2, we don't leak any Hibernate or Hibernate  
> Search interfaces into the user API which again IMO is a good thing.

You can use your own Scrolalble interface, that's fair. Essentially  
Search should look natural to cache users, not Hibernate users :)

>
> Thoughts, comments?
>
> Cheers
> Manik
>
>
>
>
> On 24 Jun 2008, at 11:47, Navin Surtani wrote:
>
>>
>>
>> Begin forwarded message:
>>
>>> From: Emmanuel Bernard <emmanuel at hibernate.org>
>>> Date: 24 June 2008 08:19:03 BST
>>> To: Navin Surtani <navin at surtani.org>
>>> Subject: Re: More hibernate questions
>>>
>>> Scroll is more important than iterate because it allows to read  
>>> objects s a window and get rid of them on a regular basis without  
>>> facing out of memory exception.
>>> I think it's used more often than iterate
>>>
>>> On  Jun 23, 2008, at 18:17, Navin Surtani wrote:
>>>
>>>> Hey again -
>>>>
>>>> I have a CacheQueryImpl class that extends the FullTextQuery  
>>>> interface and I am implementing the methods as similar as possible.
>>>>
>>>> A couple of problems occur when you are taking in and using  
>>>> certain Hibernate objects for example. A problem lies with the  
>>>> scroll() method. I think it is very similar to the iterate()  
>>>> method and does not need to be implemented in CacheQueryImpl. Do  
>>>> you know if Hibernate users generally use this method and find  
>>>> that they need it? If so then I will try and implement it  
>>>> otherwise then I will just make it throw an exception.
>>>>
>>>> Thanks again :)
>>>> Navin.
>>>
>>
>
> --
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
>
>
>
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20080626/9ee4cc0d/attachment.html