[hibernate-dev] @FullTextFilterDef cache

[Sanne Grinovero]

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.

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 is linked to the current open IndexReader (right I hope?)
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 ?
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 <emmanuel at hibernate.org>:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>