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

Sanne Grinovero sanne.grinovero at gmail.com
Fri Aug 1 13:42:01 EDT 2008


Hello Emmanuel,

2008/7/31 Emmanuel Bernard <emmanuel at hibernate.org>:
> On  Jul 31, 2008, at 09:22, Sanne Grinovero wrote:
>> about the API, wouldn't it make more sense to have it look like a filter?
> can you give more details?

I was just thinking about the name "fullTextQuery.setShardHint("Sony");":
I wouldn't call it a "hint", but a filter as it could affect the results;
A "hint" sounds like you are trying to improve the performance in
a way that shouldn't change the result, so:

fullTextQuery.enableFullTextFilter("Sony")

and it could differ from a normal FullTextFilter only by it's concrete
implementation.
Just my 2cents, as I think the effect is the same.

the feature looks great, but in my case I would need the ability in
the ShardingStrategy to create new
indexes; what do you think about that? I mean the size of the arrays
could need to grow.
Basically all my content is "clustered" in some macrocategories, and
usually the search is done after
having selected the category: so it would be perfect to have actually
different indexes per cat.,
but eventually someone could need to add a new category, the
shardingStrategy would need to write
a new empty index.
I would like also the possibility to move away from array-indexes to
some other identifier for the shards;
in my specific case I would love to use something like the PK of the
category: this could enable
an easy filter selection (category could be the parameter of the
filter) and enable something like
"Cascade delete the index" on category removal.
This could become a special implementation of ShardingStrategy, to be
mandatory when using this kind of filtering?

btw, I've committed some more fixes for HSEARCH-241

kind regards,
Sanne



More information about the hibernate-dev mailing list