--
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 Sep 5, 2008, at 09:16, Sanne Grinovero wrote:
The API you propose is looking cleaner and much more self-explanatory;
still you may help me a bit to understand it better:
as I understood from the reference docs the filter implementation
has to be reused for BitSet caching to work,
so does this mean that if my Filter implementation
is not threadsafe I should use FilterCacheMode.NO,
and otherwise I have more choice?
Is this right? we should be more clear on this requirement.
yes that is true, let's open a JIRa issue to make that more clear.
I don't really understand the need for "AUTOMATIC/NO/YES",
if it is possible to reuse the filter (i.e. it is safe) why
shouldn't you?
The Filter instance might be obsolete as soon as it is used like a
querywrapperfilter.
Or the Filter might cache BitSet itsself (by IndexReader) and does not
need the HSearch BitSet caching layer: it has more precise information
and the cache gets obsolete before an IndexReader does.
Or your memory level is constrained.
I present a case for each in the book
The filter is linked to the current open IndexReader (right I hope?)
no, but the filter results are.
so the results wouldn't change anyway (and if they did, we would
break the repeatable-read capabilities of the current transaction).
So what is the need for having both
FilterCacheMode.RESULTS and FilterCacheMode.FILTER_INSTANCE ?
across different tx, the underlying IR could be the same (as the
lucene index has not changed) but still have the cache obsolete
(because the filter information comes form an external source/service)
After all I think the only information we need is to know if
the implementation is safe to be reused, or not.
2008/9/5 Emmanuel Bernard <[EMAIL PROTECTED]>:
I am thinking about caching and filters.
In 3.0, we cache instances of Filter by using
@FullTextFilterDef.cache=true
In 3.1, we still can cache instances of Filter using
@FullTextFilterDef(cache=true, cacheBitResult= CacheBitResults.NO)
an we can cache BitSet results by using
@FullTextFilterDef(cache=true)
//, cacheBitResult= CacheBitResults.AUTOMATIC
I think we introduced cacheBitResult to keep @FullTextFilterDef
backward
compatible. But reality is that this feature is not backward
compatible:
- a new layer of caching is automatically added if you keep the
annotation
as in 3.0. It probably won't do too much harm but add an unnecessary
indirection
Fundamentally, it seems that the annotation should be
@FullTextFilterDef(cache=FilterCacheMode.RESULTS)
@FullTextFilterDef(cache=FilterCacheMode.FILTER_INSTANCE)
@FullTextFilterDef(cache=FilterCacheMode.NO)
This will force a change from 3.0 apps to 3.1 apps but it's much
clearer.
I can't seem to find a compelling reason to have instance caching
and result
caching configurable independently.
WDYT?
--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com
| http://twitter.com/emmanuelbernard
Hibernate Search in Action (http://is.gd/Dl1)
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
