You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Kevin Manuel <ke...@gmail.com> on 2020/02/20 21:54:55 UTC

Using FunctionScoreQuery vs CustomScoreQuery

Hi,

I'm working on upgrading Lucene from 7.0.0 to the latest 8.4.1. We're using
a CustomScoreQuery to score docs/results differently based on their
distance from a the user's location and also some other factors like the
type of the document (i.e. say if we stored documents of places to eat, a
restaurant would have a different boost value vs say a bar).

In the change log it was suggested to use FunctionScoreQuery instead. From
my understanding, it looks like FunctionScoreQuery can only be used for
index-time boosts (i.e. by using a field value present in the document) but
the above use case probably needs something more dynamic due to the
distance calculation.

Was wondering if you had any suggestions on how to achieve this or if maybe
I'm misunderstanding something?

Thanks,
Kevin

Re: Using FunctionScoreQuery vs CustomScoreQuery

Posted by Kevin Manuel <ke...@gmail.com>.
I see, thank you Adrien ! I'll look into it and get back to you if I have
any questions.

On Fri, Feb 21, 2020 at 1:45 AM Adrien Grand <jp...@gmail.com> wrote:

> Hi Kevin,
>
> FunctionScoreQuery can also work with dynamically-computed values, you just
> need to provide it with a DoubleValuesSource that computes values
> dynamically. The factory methods that exist in the DoubleValuesSource class
> all work with indexed data, but it is also possible to write a custom
> implementation.
>
> I also wonder whether you saw LatLonPointDistanceFeatureQuery, which is an
> efficient way to boost hits based on geo-distance.
>
> On Thu, Feb 20, 2020 at 10:55 PM Kevin Manuel <ke...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I'm working on upgrading Lucene from 7.0.0 to the latest 8.4.1. We're
> using
> > a CustomScoreQuery to score docs/results differently based on their
> > distance from a the user's location and also some other factors like the
> > type of the document (i.e. say if we stored documents of places to eat, a
> > restaurant would have a different boost value vs say a bar).
> >
> > In the change log it was suggested to use FunctionScoreQuery instead.
> From
> > my understanding, it looks like FunctionScoreQuery can only be used for
> > index-time boosts (i.e. by using a field value present in the document)
> but
> > the above use case probably needs something more dynamic due to the
> > distance calculation.
> >
> > Was wondering if you had any suggestions on how to achieve this or if
> maybe
> > I'm misunderstanding something?
> >
> > Thanks,
> > Kevin
> >
>
>
> --
> Adrien
>

Re: Using FunctionScoreQuery vs CustomScoreQuery

Posted by Adrien Grand <jp...@gmail.com>.
Hi Kevin,

FunctionScoreQuery can also work with dynamically-computed values, you just
need to provide it with a DoubleValuesSource that computes values
dynamically. The factory methods that exist in the DoubleValuesSource class
all work with indexed data, but it is also possible to write a custom
implementation.

I also wonder whether you saw LatLonPointDistanceFeatureQuery, which is an
efficient way to boost hits based on geo-distance.

On Thu, Feb 20, 2020 at 10:55 PM Kevin Manuel <ke...@gmail.com>
wrote:

> Hi,
>
> I'm working on upgrading Lucene from 7.0.0 to the latest 8.4.1. We're using
> a CustomScoreQuery to score docs/results differently based on their
> distance from a the user's location and also some other factors like the
> type of the document (i.e. say if we stored documents of places to eat, a
> restaurant would have a different boost value vs say a bar).
>
> In the change log it was suggested to use FunctionScoreQuery instead. From
> my understanding, it looks like FunctionScoreQuery can only be used for
> index-time boosts (i.e. by using a field value present in the document) but
> the above use case probably needs something more dynamic due to the
> distance calculation.
>
> Was wondering if you had any suggestions on how to achieve this or if maybe
> I'm misunderstanding something?
>
> Thanks,
> Kevin
>


-- 
Adrien