Closed (works as designed)
Project:
Apache Solr Search
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
14 Apr 2011 at 19:48 UTC
Updated:
8 Feb 2012 at 11:22 UTC
Jump to comment: Most recent file
Comments
Comment #1
jhedstromThis patch changes the input element to a text field.
Comment #2
bwinett commentedShouldn't you use an cck integer field rather than a text field?
Comment #3
jhedstromCCK isn't a dependency of apachesolr though.
Comment #4
pwolanin commentedIt seems like have a select list provided some useful hints?
Anyhow - perhaps some other boost was too strong, like on "changed"?
I'm a little reluctant to change the UI this much - especially since in some cases (e.g. for query fields) we have to have the option to "Ignore" the field. If were to change it like this it seems like we'd need validation, and perhaps want to truncate at one or 2 decimals?
Comment #5
jhedstromRegarding the other field boosting, extensive testing was done. All other bias fields were set to ignore (boost 0), and the content type that was needed to float to the top was set to 21. Still, the underlying data that was indexed had much richer density in the supposedly ignored content types, so those continued to float to the top. Even at a 0 to 2000 boost ratio, the undesired content types were higher than the boosted one. The Fibonacci numbers start looking really bizarre when they get higher...so if the UI is to continue using a select list, perhaps a sequence of 21, 100, 1000, 10000, 100000 would work?
My other idea is to implement a 'customize' link that would open a text field next to each select list, but this is drastically more work.
Comment #6
pwolanin commented@jhedstrom - I think dww contributed a patch for the # indexed per cron run selector to show the actual variable value if it's not in the normal options. Doesn't help with setting the value (use drush) but at least mitigates confusion afterward.
Comment #7
jhedstrom@pwolanin thanks, I'll take a look.
Comment #8
jessehsI recreated the patch in comment 1, but also added textfields to "sticky" and "promoted" settings in the Result biasing form on the same page. This way, if you set the sticky field to 21000, a sticky node becomes super-sticky in search results!
Comment #9
pwolanin commentedFor 6.x I don't think we will change to text fields - see above about making the drop-down display the value that's actually set.
Comment #10
nick_vhClosing this. A form alter would fix this easily and the issue is a bit out of date also.
Comment #11
quotesbro commentedThe same thing. Changing the bias values does not affect to the order of search results. It looks like a bug. What about adding high values (like 21000) to the select list?
Comment #12
nick_vhThen you probably have configured the bias wrongly or 1 field is overpowering all the other biases.
Same answer : form_alter and change the values?