What your could is that you store two versions of a field by using a
multi field type:
One field would be analysed and one wouldn't be analysed. The not
analysed field will be used for exact matches.
You then define a boolean query with two should clauses. One clause
holds a query for
the analysed field. The other clause holds a query for the not
analysed field, but
is wrapped in a custom_boost_factor query:
This query allows you to impact the score hits in the not analysed
field higher by specifying a boost factor.
The scoring formula gives hits in shorter fields a higher positive
boost than for hits in longer fields.
The length of a field is measured in number of terms. This already
might result in the behavior you want.
This scoring behavior is in place as long as omit_norms is set to
false on string field types, which is the default.
On 30 July 2012 02:51, Matt firstname.lastname@example.org wrote:
I have a search for a string against some 'names'. I want to prioritize an
exact match as the first result returned and all other matches, or hits, to
Could I or should I have a request which combines a 'must' with a 'should'?
If I search for 'John' and got a heap of records back but one happened to be
'John' with no last name, not 'John Brown' or 'John Smith' or 'Johnny', an
exact string match, I want to get that result first.