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 <emman...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
