[hibernate-dev] Should we deprecate @Similarity

Emmanuel Bernard emmanuel at hibernate.org
Wed Oct 2 09:10:13 EDT 2013


Yes that was a mistake. It was done as you say to make things simpler
for the user but it has created headaches for us since then.

On Thu 2013-09-19 16:15, Sanne Grinovero wrote:
> Discussing about some hibernate-search-engine complexities with Hardy
> on IRC, we came to the agreement that the way @Similarity behaves
> today was a mistake, so we're proposing to deprecate it in 4.4.
> 
> Reasoning follows.
> 
> There is a strong requirement in Lucene that all operations on the
> same index need to use the same Similarity implementation. We infer
> the org.apache.lucene.search.Similarity to be used on a specific index
> from either:
> 
> - the similarity property from the configuration file, which is
> positioned on an index name
> - the @Similarity annotation positioned on an indexed entity
> 
> The trouble is about all these options needing to be consistent; first
> problem is there isn't a precedence rule: if one of them is not
> specified, we assume the user is using the other way to configure
> things. But also different entities might be sharing the same index,
> which leads to needing to verify that at least the user isn't
> specifying some contradictory option.
> 
> This all gets more confusing when you introduce the notion of
> dynamically added new entities (a feature used by Infinispan) and/or
> Dynamic Sharding, in which the properties of some indexes might
> conflict with the specified @Similarity, but we might notice this only
> at runtime rather than at bootstrap. Failing to load a class at this
> point is far more annoying to the users than to fail the health-check
> at bootstrap time.
> 
> So the proposal:
> drop the @Similarity annotation and use properties exclusively.
> Properties are more suited for this as they are set on a per-index
> base, which is what matters in this case.
> 
> Downside:
> I guess lots of people where using a single index per type, and for
> those there was no danger to simply specify a @Similarity. We lose
> this straight-forward way of things, but I'd argue that if you're in
> the business of specifying a custom Similarity, you're a very advanced
> user and wouldn't mind setting a one-liner in your configuration file.
> 
> Do we agree?
> 
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


More information about the hibernate-dev mailing list