While working on a recent project, the bias values appeared to not have any effect. Only when I manually changed one type's value to 21000 did the desired bias start to work.

The current admin UI uses a select list.

My initial idea was to continue adding Fibonacci sequence numbers to that list, but it seems simpler to change this to a text field.

Patch forthcoming.

Comments

jhedstrom’s picture

Status: Active » Needs review
StatusFileSize
new1.49 KB

This patch changes the input element to a text field.

bwinett’s picture

Shouldn't you use an cck integer field rather than a text field?

jhedstrom’s picture

CCK isn't a dependency of apachesolr though.

pwolanin’s picture

Version: 6.x-1.2 » 6.x-1.x-dev
Status: Needs review » Needs work

It 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?

jhedstrom’s picture

Regarding 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.

pwolanin’s picture

@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.

jhedstrom’s picture

@pwolanin thanks, I'll take a look.

jessehs’s picture

StatusFileSize
new2.9 KB

I 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!

pwolanin’s picture

For 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.

nick_vh’s picture

Status: Needs work » Closed (won't fix)

Closing this. A form alter would fix this easily and the issue is a bit out of date also.

quotesbro’s picture

Component: User interface » Code
Category: feature » bug
Status: Closed (won't fix) » Active

the bias values appeared to not have any effect. Only when I manually changed one type's value to 21000 did the desired bias start to work.

The 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?

nick_vh’s picture

Status: Active » Closed (works as designed)

Then you probably have configured the bias wrongly or 1 field is overpowering all the other biases.
Same answer : form_alter and change the values?