6:15 a.m.
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.
I think the only methods in FullTextQuery that are relevant and that
should be carried across to CacheQuery are:
* list()
* iterator();
* setFirstResult(int i);
* setMaxResults(int i);
* setFetchSize(int i);
* getResultSize();
* setSort();
I think all of the rest - such as filters, criteria and projections -
are irrelevant to a query on a cache. WDYT? Emmanuel?
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().
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.
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.
Thoughts, comments?
Cheers
Manik
On 24 Jun 2008, at 11:47, Navin Surtani wrote:
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Date: 24 June 2008 08:19:03 BST
> To: Navin Surtani <navin(a)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(a)jboss.org
7:48 a.m.
--
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(a)hibernate.org>
>> Date: 24 June 2008 08:19:03 BST
>> To: Navin Surtani <navin(a)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(a)jboss.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:12 p.m.
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
6024
days inactive
6026
days old
2 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Manik Surtani