[hibernate-dev] JBoss Cache Searchable interfaces

[Manik Surtani]

On 26 Jun 2008, at 13:48, Emmanuel Bernard wrote:

<SNIP />

>> * iterator();
> don't think it's that useful in practice, scroll is probably more  
> practical as it lazily loads Lucene data (contrary to iterator)

Then why don't we just lazily load Lucene data into the iterator and  
drop scroll()?  I see supporting both as superfluous.  And iterator()  
is more familiar to devs.

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

+1, good point.  We'd need a close() method on the QueryResultIterator.

I see just returning a null if the object is not in the cache as  
something people would expect.

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

If you think eager loading of Lucene data is something people would  
find useful, we could have 2 separate implementations of the  
QueryResultIterator - a QRILazyImpl and a QRIEagerImpl.  And the  
interface to obtain these could be on the CacheQuery interface:

CacheQuery.iterator(boolean lazy);

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

Yup.  :-)

--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org