[hibernate-dev] HSearch: Using sharding and avoiding query on multiple shards

[Emmanuel Bernard]

On  Jun 10, 2009, at 19:12, Sanne Grinovero wrote:

> you're right we need some way to know which filters don't need to be
> applied on the "lowlevel" IndexSearcher,
> but adding a flag breaks backwards compatibility, and using a type

We're breaking backward compatibility by changing the  
IndexShardingStrategy contract.

> will get us to use ugly "instanceof"; they're not
> bad solutions but what do you think of using a new option of the
> @FullTextFilterDef ?

Right thats' what I meant by flag. I am on the fence. In the initial  
implementation I've committed, I've used a ShardSensitiveOnlyFilter  
interface

@FullTextFilterDef(name="customer", impl=ShardSensitiveOnlyFilter.class)

as opposed to
@FullTextFilterDef(name="customer", impl=void.class,  
shardSensitiveOnly=true)

or
@FullTextFilterDef(name="customer", shardSensitiveOnly=true)
if we start to default impl (which can lead to other user errors  
unfortunately)

Each solution has its set of ugliness, but I am open to suggesting  
arguments. Either solution would work for me
>
> We could also consider that such a filter implementation is tightly
> coupled to the ShardingStrategy itself; it could make
> sense to have the filter+shardingStrategy implementations to be merged
> in one class, and have a keyword ( "shardsFilter" ?)
> to enable THE one sharding-based filter.

not sure what you mean. We can certainly reduce the amount of  
implementation work in  
IndexShardingStrategy#getDirectoryProvidersForQuery (using annotations  
to declare which filter we are itnerested in etc etc) but I'd rather  
know how people use this feature first before adding some convention  
over configuration.

> This would reduce considerably the amount of code to be written to use
> this feature; the filter parameters would be delegated directly to the
> shardingStrategy,
> which doesn't need to find out which filters it's interested in. There
> would be no dump filter implementation at all, it just looks like you
> use
> a filter from an API point of view but you're actually configuring the
> sharding strategy to return what you need.

Not sure how that eliminates the dump filter. The flag approach does,  
not the coupling between Sharding and Filter.