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 <[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