Re: [hibernate-dev] JBoss Cache Searchable interfaces
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(a)jboss.org