[hibernate-dev] Interceptor question

Hardy Ferentschik hardy at hibernate.org
Sat May 12 03:58:05 EDT 2012

> Since the filter is user defined, based on the fact that the user
> *knows* the blog needs to be indexed only when [businessrule],
> it's not hard to adapt the code using an
> if [businessrule] {
> fulltextSession#index( e );
> }
> else {
> log.discardBlogDRAFTFromIndex( e );
> }

Not hard, but not expected. If I were a user I would wonder why I have to jump through these hoops, even though I just configured an interceptor. Even worth, it is not documented and even worse the mass indexer suddenly applies it.

> Maybe we shouldn't imply they are the same. Obviously the "old style"
> provides far more control, this is just showcasing once more the
> additional control the user has.

Why not? Why making it even harder for users. Yet another little detail to keep in mind. Why not keeping it simple?

> Let's put it the other way around: you want to use #purge( A ).
> Why would you use the method? I guess because you want to remove
> something from the index. And you want it to happen *now*, not start
> to argue with the system ..

I was wondering about this as well and initially I thought ,hey maybe purging is different and one has to behave differently. However, thinking more about it, I think the interceptor should be even applied there. First I argue that not many users will have a need to change the delete/purge operation. BUT if they do, they might have a reason, so it makes only sense to not delete the entity on purge either.

Bottom line is that applying the interceptors consistently harbors much less surprises for the user and gives him a much simpler model of "how Search works". A user who does not know the intrinsic implementation details will always create some sort of model how he thinks the frameworks works. Why confusing the user with different behavior between automatic indexing, index API and mass indexer. Conceptually they should all do thing.

> Would you expect Search to prevent you from doing that if the indexing
> policy doesn't agree? And should it happen silently, or would you
> expect an exception like
> throw new SearchException( " HAHA we won't allow you to remove that!
> No way! Go do your homework and implement a better filter strategy, or
> go edit the index with an hex editor. No way we help you out!" )

What are you trying to do here? The user has written and configured the interceptor, so it he wants to prevent deletion, so be it. And yes, if push comes to shove he will have to delete the index manually. 


More information about the hibernate-dev mailing list