Basically I need a function to convert a user-proposed term to a
series of proposals
of "similar" terms but giving a higher rank to the terms I'd prefer
him to choose as they
are the correct names used in my domain.
You can think of it as a spellchecker/dictionary (using synonyms
toos), but giving priority to
a selected form of each term, known as the "root", or the standard
form in the domain.
This is the simple explanation which I believe is useful in all indexing modes;
actually I'm also going to use it for the 2 reasons you are
listing, and it's not a problem for me as I rebuild the index
regularly and prefer for
several reasons to pre-compute the boosts needed for "categories in
marketing mood"
and "fade by age" effects.
2009/4/30 Emmanuel Bernard <emmanuel(a)hibernate.org>:
What's your use case?
I am not against that feature but I don't think it covers all use cases:
- I want a higher boost for more recent documents
- I change priority in my categories depending on the marketing mood
Said otherwise, can have a true dynamic boost defined at query time, not at
indexing time.
I think Solr has something named FunctionQuery that can do that.
On Apr 29, 2009, at 16:47, Sanne Grinovero wrote:
> Hello,
> I'm currently needing to be able to define a per-entity INSTANCE
> different Boost, not just the type.
>
> Currently I could obtain this functionality by using a custom
> classbridge, but the entity is quite complex and building my own
> classbridge I will have to map all fields myself loosing the
> flexibility of annotations for the current type and
> all @IndexedEmbedded.
>
> I'd like to add a new parameter to @Boost; currently it has a float
> mandatory value,
> I'd like to add a new parameter:
>
> Class<BoostScorer> impl();
>
> where BoostScorer is an interface having something like
>
> public float score(Object value);
>
> The annotation would default to an implementation returning constant 1.0f.
>
> This would have an interaction with the existing "value" parameter:
> IMHO they should
> multiply each other, so I'd change the existing value to also have a
> default of 1.0f
> and people might want to change one or both values.
>
> Setting both values might be useful to reuse the same impl on
> different types/fields
> and still be able to statically scale the result from the
> score(Object) function, without having to
> rewrite a new implementation.
>
> What do you think?
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev