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
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
