Do not use index time boosting, please. When something is deprecated,
the usual process is that that functionality is supported for one
major version after deprecation, then the devs are free to remove it.
Index time boosting is not supported in 7.0 even though it is in 6x,
from CHANGES.txt, the 7.
Thanks for the reply Amit.
I have Solr 6.6 source code and I can still see the code which sets the
index level boost value.
If the class name is handy for you , could you please tell me where we will
calculate the score of a document. so that i can just go through the code.
Thanks,
Venkat.
On T
Hi Venkat,
FYI: Index time boosting has been deprecated from latest versions of Solr:
https://issues.apache.org/jira/browse/LUCENE-6819.
Not sure which version you are on, but best consider the comments on the
JIRA before using it.
Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.l
thank you james for the feedback - i appreciate it.
ultimately - i was trying to decide if i was missing the boat by ONLY using
query time boosting, and i should really be using index time boosting.
but after your reply, reading the solr book, and looking at the lucene dox -
it looks like index-t
m]
Sent: Tuesday, May 22, 2012 3:06 PM
To: solr-user@lucene.apache.org
Subject: RE: index-time boosting using DIH
thanks for the reply,
so to use the $docBoost pseudo-field name, would you do something like below
- and would this technique likely inc
thanks for the reply,
so to use the $docBoost pseudo-field name, would you do something like below
- and would this technique likely increase my total index time?
...
--
View this message in context:
http://lucene.472066.n3.nabble.com/index-tim
See http://wiki.apache.org/solr/DataImportHandler#Special_Commands and the
$docBoost pseudo-field name.
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: geeky2 [mailto:gee...@hotmail.com]
Sent: Tuesday, May 22, 2012 2:12 PM
To: solr-user@lucene.
--Original Message-
From: Shalin Shekhar Mangar [mailto:shalinman...@gmail.com]
Sent: Donnerstag, 28. Juli 2011 12:37
To: solr-user@lucene.apache.org
Subject: Re: Index time boosting with DIH
On Thu, Jul 28, 2011 at 3:56 PM, Bürkle, David wrote:
> Can someone point me to an example fo
On Thu, Jul 28, 2011 at 3:56 PM, Bürkle, David wrote:
> Can someone point me to an example for using index time boosting with the
> DataImportHandler.
>
>
You can use the special flag variable $docBoost to add a index time boost.
http://wiki.apache.org/solr/DataImportHandler#Special_Commands
--
Thanks Iorixxx... Boosting is working while using DIH to import XML.
Thanks,
SRD
--
View this message in context:
http://lucene.472066.n3.nabble.com/Index-time-boosting-is-not-working-with-boosting-value-in-document-level-tp1649072p1693423.html
Sent from the Solr - User mailing list archive at
> Thanks a ton Eric and Iorixxx.
> Since I used DIH to import XML data, boosting was not
> reflected in score.
> When I used /update to import XML data, boosting was
> considered for scoring
> and able to see the intended data on top 10 results.
> Could you please let me know how to make boosting v
Thanks a ton Eric and Iorixxx.
Since I used DIH to import XML data, boosting was not reflected in score.
When I used /update to import XML data, boosting was considered for scoring
and able to see the intended data on top 10 results.
Could you please let me know how to make boosting value to be re
> Eric,
> Score is not coming properly even after
> giving boost value in document
> and field level.
> Please find the solrconfig.xml,
> schema.xml, data-config.xml, the feed and
> the score & query.
> Doc with id 'ABCDEF/L' is boosted and doc
> with id 'MA147LL/A' is not
> boosted, but b
Eric,
Score is not coming properly even after giving boost value in document
and field level.
Please find the solrconfig.xml, schema.xml, data-config.xml, the feed and
the score & query.
Doc with id 'ABCDEF/L' is boosted and doc with id 'MA147LL/A' is not
boosted, but both are returning s
Boosting doesn't necessarily put documents in a particular order. Boosting
just #tends#
to make the doc score higher. What do you see if you add &debugQuery=on?
That'll tell
you why docs scored as they did.
Best
Erick
On Thu, Oct 7, 2010 at 11:39 AM, Shanmugavel SRD
wrote:
>
> We are having 10 d
No, I wasn't thinking of the _val_ hack, you can boos via the
q parameter as you indicated: i_authors:tilly^5 i_title:tilly^10
Do note, though, that you'll never be able to absolutely
guarantee the ordering you want, although by using "crazy values'
you may not be able to tell ...
Best
Erick
On
thanks for replying erick,
We are currently using dismax but for this particular client we have coupled
their implementation to standard parser and will be difficult to switch,
although i might just have to bite the bullet for this.
"which you can do without dismax BTW, although you have to int
Have you tried running the queries through with &debugQuery=true?
It may well be that, for certain documents, the lower-boosted fields
are still overwhelming the contribution to scoring from the higher-boosted
fields for the documents in question.
The problem is that index-time boosting is fairly
: I had working index time boosting on documents like so:
:
: Everything was great until I made some changes that I thought where no
: related to the doc boost but after that my doc boosting appears to be
: missing.
:
: I'm having a tough time debugging this and didn't have the sense to version
What are you really trying to accomplish here? Because index time boostingis
a way of saying "I care about matches in this field of this document
X times more than other documents" whereas search time boosting
expresses "elevate the relevance of any document where this term matches"
>From your ex
Yep, sounds like you got it. Query-time boosting is what you want.
however, the above document *will* have a higher
score, in general, because the "title" portion was nearly
half of the "text" field.
Well, if you boost *all* of the "title" fields by 100, it also has the
net effect of boosting
ahh, after rereading this about 20 times today 8-)
i think i finally "get it" (your final question below).
if i do index-time boosts, and search only "text" (default field)
the boosts will propogate into "text", but only insofar that the
document will weight higher when a phrase is found in the "
ok, great to know -- all this is invaluable.
i'm stashing away "ideas" like this for the future (because..)
i think for now i'll stick with XSL transforming the fields to lowercase
because we already need this small XSLT from our item XML to
XML that solr can index.
-t
Chris Hostetter wrote:
oh, and yes, i've always understood, thankfully, that queries
of
"q=commute&fl=title"
and
"q=title:commute&fl=title"
are *quite* different
(but that is probably mostly due to my prior experience with
lucene with our current broken SE 8-)
-t
Mike Klaas wrote:
On 12/5/06, Tracey Jaquith
Hi Mike,
OK, I guess my "problem" is more of a partially still coming up
to speed / partially wanting to be lazy.
If I make a dismax handler called "dissed", I'd like it to "work"
whether or not i pass in "commute" or "title:commute" to the query.
(Now I *do* realize those are two completely dif
On 12/5/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: Indeed--those are different queries. The "fl" parameter controlled
: the stored fields returned by Solr; it does not affect which documents
: are returned. The first query asks for the titles of all documents
: containing the word "commu
: so for my dwindling number of remaining "string" types, in my XSL
: transform (on the input to index the doc) i'll lowercase them all, too 8-)
I don't beleive that is strictly neccessary, these two field types should
be functionally equivilent...
...so i'm p
: > (For example, I do "indent=on&fl=title&q=commute" in a wget and grep the
: > results
: > for and then grep -i for commute, there are 23 hits. But doing
: > "&q=title:commute" only returns one of those hits..)
:
: Indeed--those are different queries. The "fl" parameter controlled
: the sto
wow, that makes sense now. my bad.
OK, great. further testing shows "you mean what you say" -- not
only verbatim, but case sensitive.
so for my dwindling number of remaining "string" types, in my XSL
transform (on the input to index the doc) i'll lowercase them all, too
8-)
thanks!!
--t
Yo
On 12/5/06, Tracey Jaquith <[EMAIL PROTECTED]> wrote:
Now I have one new mystery that's popped up for me.
With std req handler, this simple query
q=title:commute
is *not* returning me all documents that have the word "commute" in the
title.
There must be some other filter/clause or something
On 12/5/06, Tracey Jaquith <[EMAIL PROTECTED]> wrote:
Now I have one new mystery that's popped up for me.
With std req handler, this simple query
q=title:commute
is *not* returning me all documents that have the word "commute" in the
title.
There must be some other filter/clause or something
Hi Yonik!
Yonik Seeley wrote:
On 12/5/06, Tracey Jaquith <[EMAIL PROTECTED]> wrote:
Quick intro. Server Engineer at Internet Archive.
I just spent a mere 3 days porting nearly our entire site to use your
*wonderful* project!
I, too, am looking for a kind of "boosting".
If I understand your re
One last thing to keep in mind is the tradeoffs:
Querying a single all encompasing "text" field will be faster, but the
scoring won't be as relevant. The types of queries dismax generates
can get you better relevance, at the cost of performance.
-Yonik
On 12/5/06, Chris Hostetter <[EMAIL PROTEC
: > [We are most interested in always having "title", "description", and a
: > few other
: > fields boosted. We have both user queries of phrases/words as well as
: > "field-specific" queries (eg: "mediatype:moves AND collection:prelinger")
: > so my thought is std might be better than dismax.
On 12/5/06, Tracey Jaquith <[EMAIL PROTECTED]> wrote:
Quick intro. Server Engineer at Internet Archive.
I just spent a mere 3 days porting nearly our entire site to use your
*wonderful* project!
I, too, am looking for a kind of "boosting".
If I understand your reply here, if i reindex *all* my
Hi all,
[initially I replied to a thread which went to Mike Klass email so after
his helpful
reply, I'm trying to merge this back into the list discussion]
Quick intro. Server Engineer at Internet Archive.
I just spent a mere 3 days porting nearly our entire site to use your
*wonderful* proj
: We'll start with "OR", because I think an all-terms default is a really
: bad idea. If someone is searches for "X-Men 3: The Final Battle", we
: need to show them "X-Men 3: The Last Stand".
BooleanQuery.setMinimumNumberShouldMatch can help reduce the cruft with
this approach .. the dismax handl
: Is fq documented anywhere??? It's very useful for speeding up complex
i just added it to CommonQueryParameters
-Hoss
On Oct 20, 2006, at 2:34 PM, Walter Underwood wrote:
We have a well-developed browsing design, so I'd rather not mix
facets in with that. Two other things work against using facets:
most of our queries are known-item searches, and I think that
facets work best when there is very broad agreement
On 10/20/06 11:17 AM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote:
> That definitely seems doable.
> How big is your index?
Currently, the index is 65,000 movies plus actors and directors. A pretty
small corpus.
> What's the form of your queries (AND, or sloppy phrase queries I'd imagine?)
We'll s
On 10/20/06, Walter Underwood <[EMAIL PROTECTED]> wrote:
On 10/20/06 10:24 AM, "Mike Klaas" <[EMAIL PROTECTED]> wrote:
> Finally, it can be much faster to search a single field rather than
> multiple fields. One hacky way of achieving this is to make a field
> which receives a single copy of co
On 10/20/06, Walter Underwood <[EMAIL PROTECTED]> wrote:
On 10/20/06 10:24 AM, "Mike Klaas" <[EMAIL PROTECTED]> wrote:
> Finally, it can be much faster to search a single field rather than
> multiple fields. One hacky way of achieving this is to make a field
> which receives a single copy of co
On 10/20/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 10/20/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
> Finally, it can be much faster to search a single field rather than
> multiple fields. One hacky way of achieving this is to make a field
> which receives a single copy of contents and eight
On 10/20/06 10:24 AM, "Mike Klaas" <[EMAIL PROTECTED]> wrote:
> Finally, it can be much faster to search a single field rather than
> multiple fields. One hacky way of achieving this is to make a field
> which receives a single copy of contents and eight copies of title.
> This is imperfect, as i
On 10/20/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
Index-time boosts can be set per-document or per-document-field.
There is no facility for setting the boost of a part of text added to
a field (as you suggest above) (which is really a shame, as such
functionality would lend huge flexibility to i
On 10/20/06, Walter Underwood <[EMAIL PROTECTED]> wrote:
I'm trying to figure out how to set per-field boosts in Solr at index time.
For example, if I want the title to be boosted by a factor of 8, I could
do that in a query, or I could add the title text with a boost of 8 to the
default text fie
On 10/20/06, Walter Underwood <[EMAIL PROTECTED]> wrote:
I'm trying to figure out how to set per-field boosts in Solr at index time.
The update XML syntax supports both document boosts and field boosts.
http://wiki.apache.org/solr/UpdateXmlMessages
A document boost is simply multiplied into the
47 matches
Mail list logo
