>>> +0,8 to optionally (with a boolean) enable interception on those >>> methods. I guess it might be handy, but I'm not fully convinced on >>> their use and it's yet-another-method, we're getting a bit complex. >>> At least it's better than always applying the interceptor as the >>> missing method would make it clear that this wouldn't work on >> >> An alternative to overloading these methods would be to add something like: >> >> void FullTextSession#enableInterceptors(boolean) >> boolean FullTextSession#areInterceptorsEnabled() > > That's a very cool idea. What about > FullTextSession#enableIndexingInterceptors(boolean) ?
Sure, that's how it should be called in the end. The thing I like about this solution is also that it is inline with how we do similar things in (Fulltext)Session. >>> #purgeAll: as Emmanuel pointed out that's not going to fly. >> >> Not sure why not > > You might be right, if all what is indexed can always be nuked. Is > that always the case? Remember the implementation uses a single delete > statement on the index: all documents of class X are removed. It's > hard to express the user defined filter in those terms, unless we > extend the complexity of EntityIndexingInterceptor to rely on the user > to define this case. fair point --Hardy _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
