Re: Boost query at search time according set of roles with least performance impact

2015-11-16 Thread Alessandro Benedetti
 is the readability that is stopping you to use the bq parameter with
all your roles ?
A custom function is off course  a way, but why you think is going to
satisfy better your requirement in comparison with the bq ?

Cheers

On 13 November 2015 at 18:41, Andrea Open Source <
andrearoggerone.o...@gmail.com> wrote:

> Hi Alessandro,
> Thanks for answering. Unfortunately bq is not enough as I have several
> roles that I need to score in different ways. I was thinking of building a
> custom function that reads the weights of the roles from solr config and
> applies them at runtime. I am a bit concerned about performance though and
> that's the reason behind my question. What's your thought about such
> solution?
>
> King Regards,
> Andrea Roggerone
>
> > On 09/nov/2015, at 12:29, Alessandro Benedetti 
> wrote:
> >
> > ehehe your request is kinda delicate :
> > 1)  I can't store the
> > payload at index time
> > 2) Passing all the weights at query time is not an option
> >
> > So you seem to exclude all the possible solutions ...
> > Anyway, just thinking loud, have you tried the edismax query parser and
> the
> > boost query feature?
> >
> > 1) the first strategy is the one you would prefer to avoid :
> > you define the AuthorRole, then you use the Boost Query parameter to
> boost
> > differently your roles :
> > AuthorRole:"ADMIN"^100 AuthorRole:"ARCHITECT"^50 ect ...
> > If you have 20 roles , the query could be not readable.
> >
> > 2) you index the "weight" for the role in the original document.
> > The you use a Boost Function according to your requirement ( using there
> > "weight" field)
> >
> > Hope this helps,
> >
> > Cheers
> >
> > e.g. from the Solr wiki
> > The bq (Boost Query) Parameter
> >
> > The bq parameter specifies an additional, optional, query clause that
> will
> > be added to the user's main query to influence the score. For example, if
> > you wanted to add a relevancy boost for recent documents:
> > q=cheese
> > bq=date:[NOW/DAY-1YEAR TO NOW/DAY]
> >
> > You can specify multiple bq parameters. If you want your query to be
> parsed
> > as separate clauses with separate boosts, use multiple bq parameters.
> > The bf (Boost Functions) Parameter
> >
> > The bf parameter specifies functions (with optional boosts) that will be
> > used to construct FunctionQueries which will be added to the user's main
> > query as optional clauses that will influence the score. Any function
> > supported natively by Solr can be used, along with a boost value. For
> > example:
> > recip(rord(myfield),1,2,3)^1.5
> >
> > Specifying functions with the bf parameter is essentially just shorthand
> > for using the bq param combined with the {!func} parser.
> >
> > For example, if you want to show the most recent documents first, you
> could
> > use either of the following:
> > bf=recip(rord(creationDate),1,1000,1000)
> >  ...or...
> > bq={!func}recip(rord(creationDate),1,1000,1000)
> >
> > On 6 November 2015 at 16:44, Andrea Roggerone <
> > andrearoggerone.o...@gmail.com> wrote:
> >
> >> Hi all,
> >> I am working on a mechanism that applies additional boosts to documents
> >> according to the role covered by the author. For instance we have
> >>
> >> CEO|5 Architect|3 Developer|1 TeamLeader|2
> >>
> >> keeping in mind that an author could cover multiple roles (e.g. for a
> >> design document, a Team Leader could be also a Developer).
> >>
> >> I am aware that is possible to implement a function that leverages
> >> payloads, however the weights need to be configurable so I can't store
> the
> >> payload at index time.
> >> Passing all the weights at query time is not an option as we have more
> than
> >> 20 roles and query readability and performance would be heavily
> affected.
> >>
> >> Do we have any "out of the box mechanism" in Solr to implement the
> >> described behavior? If not, what other options do we have?
> >
> >
> >
> > --
> > --
> >
> > Benedetti Alessandro
> > Visiting card : http://about.me/alessandro_benedetti
> >
> > "Tyger, tyger burning bright
> > In the forests of the night,
> > What immortal hand or eye
> > Could frame thy fearful symmetry?"
> >
> > William Blake - Songs of Experience -1794 England
>



-- 
--

Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti

"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"

William Blake - Songs of Experience -1794 England


Re: Boost query at search time according set of roles with least performance impact

2015-11-13 Thread Andrea Open Source
Hi Alessandro,
Thanks for answering. Unfortunately bq is not enough as I have several roles 
that I need to score in different ways. I was thinking of building a custom 
function that reads the weights of the roles from solr config and applies them 
at runtime. I am a bit concerned about performance though and that's the reason 
behind my question. What's your thought about such solution?

King Regards,
Andrea Roggerone

> On 09/nov/2015, at 12:29, Alessandro Benedetti  wrote:
> 
> ehehe your request is kinda delicate :
> 1)  I can't store the
> payload at index time
> 2) Passing all the weights at query time is not an option
> 
> So you seem to exclude all the possible solutions ...
> Anyway, just thinking loud, have you tried the edismax query parser and the
> boost query feature?
> 
> 1) the first strategy is the one you would prefer to avoid :
> you define the AuthorRole, then you use the Boost Query parameter to boost
> differently your roles :
> AuthorRole:"ADMIN"^100 AuthorRole:"ARCHITECT"^50 ect ...
> If you have 20 roles , the query could be not readable.
> 
> 2) you index the "weight" for the role in the original document.
> The you use a Boost Function according to your requirement ( using there
> "weight" field)
> 
> Hope this helps,
> 
> Cheers
> 
> e.g. from the Solr wiki
> The bq (Boost Query) Parameter
> 
> The bq parameter specifies an additional, optional, query clause that will
> be added to the user's main query to influence the score. For example, if
> you wanted to add a relevancy boost for recent documents:
> q=cheese
> bq=date:[NOW/DAY-1YEAR TO NOW/DAY]
> 
> You can specify multiple bq parameters. If you want your query to be parsed
> as separate clauses with separate boosts, use multiple bq parameters.
> The bf (Boost Functions) Parameter
> 
> The bf parameter specifies functions (with optional boosts) that will be
> used to construct FunctionQueries which will be added to the user's main
> query as optional clauses that will influence the score. Any function
> supported natively by Solr can be used, along with a boost value. For
> example:
> recip(rord(myfield),1,2,3)^1.5
> 
> Specifying functions with the bf parameter is essentially just shorthand
> for using the bq param combined with the {!func} parser.
> 
> For example, if you want to show the most recent documents first, you could
> use either of the following:
> bf=recip(rord(creationDate),1,1000,1000)
>  ...or...
> bq={!func}recip(rord(creationDate),1,1000,1000)
> 
> On 6 November 2015 at 16:44, Andrea Roggerone <
> andrearoggerone.o...@gmail.com> wrote:
> 
>> Hi all,
>> I am working on a mechanism that applies additional boosts to documents
>> according to the role covered by the author. For instance we have
>> 
>> CEO|5 Architect|3 Developer|1 TeamLeader|2
>> 
>> keeping in mind that an author could cover multiple roles (e.g. for a
>> design document, a Team Leader could be also a Developer).
>> 
>> I am aware that is possible to implement a function that leverages
>> payloads, however the weights need to be configurable so I can't store the
>> payload at index time.
>> Passing all the weights at query time is not an option as we have more than
>> 20 roles and query readability and performance would be heavily affected.
>> 
>> Do we have any "out of the box mechanism" in Solr to implement the
>> described behavior? If not, what other options do we have?
> 
> 
> 
> -- 
> --
> 
> Benedetti Alessandro
> Visiting card : http://about.me/alessandro_benedetti
> 
> "Tyger, tyger burning bright
> In the forests of the night,
> What immortal hand or eye
> Could frame thy fearful symmetry?"
> 
> William Blake - Songs of Experience -1794 England


Re: Boost query at search time according set of roles with least performance impact

2015-11-09 Thread Alessandro Benedetti
ehehe your request is kinda delicate :
1)  I can't store the
payload at index time
2) Passing all the weights at query time is not an option

So you seem to exclude all the possible solutions ...
Anyway, just thinking loud, have you tried the edismax query parser and the
boost query feature?

1) the first strategy is the one you would prefer to avoid :
you define the AuthorRole, then you use the Boost Query parameter to boost
differently your roles :
AuthorRole:"ADMIN"^100 AuthorRole:"ARCHITECT"^50 ect ...
If you have 20 roles , the query could be not readable.

2) you index the "weight" for the role in the original document.
The you use a Boost Function according to your requirement ( using there
"weight" field)

Hope this helps,

Cheers

e.g. from the Solr wiki
The bq (Boost Query) Parameter

The bq parameter specifies an additional, optional, query clause that will
be added to the user's main query to influence the score. For example, if
you wanted to add a relevancy boost for recent documents:
q=cheese
bq=date:[NOW/DAY-1YEAR TO NOW/DAY]

You can specify multiple bq parameters. If you want your query to be parsed
as separate clauses with separate boosts, use multiple bq parameters.
The bf (Boost Functions) Parameter

The bf parameter specifies functions (with optional boosts) that will be
used to construct FunctionQueries which will be added to the user's main
query as optional clauses that will influence the score. Any function
supported natively by Solr can be used, along with a boost value. For
example:
recip(rord(myfield),1,2,3)^1.5

Specifying functions with the bf parameter is essentially just shorthand
for using the bq param combined with the {!func} parser.

For example, if you want to show the most recent documents first, you could
use either of the following:
bf=recip(rord(creationDate),1,1000,1000)
  ...or...
bq={!func}recip(rord(creationDate),1,1000,1000)

On 6 November 2015 at 16:44, Andrea Roggerone <
andrearoggerone.o...@gmail.com> wrote:

> Hi all,
> I am working on a mechanism that applies additional boosts to documents
> according to the role covered by the author. For instance we have
>
> CEO|5 Architect|3 Developer|1 TeamLeader|2
>
> keeping in mind that an author could cover multiple roles (e.g. for a
> design document, a Team Leader could be also a Developer).
>
> I am aware that is possible to implement a function that leverages
> payloads, however the weights need to be configurable so I can't store the
> payload at index time.
> Passing all the weights at query time is not an option as we have more than
> 20 roles and query readability and performance would be heavily affected.
>
> Do we have any "out of the box mechanism" in Solr to implement the
> described behavior? If not, what other options do we have?
>



-- 
--

Benedetti Alessandro
Visiting card : http://about.me/alessandro_benedetti

"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"

William Blake - Songs of Experience -1794 England


Boost query at search time according set of roles with least performance impact

2015-11-06 Thread Andrea Roggerone
Hi all,
I am working on a mechanism that applies additional boosts to documents
according to the role covered by the author. For instance we have

CEO|5 Architect|3 Developer|1 TeamLeader|2

keeping in mind that an author could cover multiple roles (e.g. for a
design document, a Team Leader could be also a Developer).

I am aware that is possible to implement a function that leverages
payloads, however the weights need to be configurable so I can't store the
payload at index time.
Passing all the weights at query time is not an option as we have more than
20 roles and query readability and performance would be heavily affected.

Do we have any "out of the box mechanism" in Solr to implement the
described behavior? If not, what other options do we have?