/ domm
I'm still maintaing a certain $project, which runs on MySQL (and Class::DBI, Template::Toolkit, mod_perl and a whole lot other stuff). Today, I got a bug report stating that the programme search cannot find a certain programm ("Help - Das Konsumentenmagazin").
So I tried the search, and it didn't work, even though the data is there. Yay, Heisenbug, I thought, and tried the query directly in the mysql shell. Didn't work either. After some tinkering I realized that 'help' is a MySQL fulltext search stopword. D'oh!
While I can see a point in making 'help' a stopword (it seems to be used quite often), it's IMO a very dumb decision to make it a stopword. People will look for 'help'!
To top it, you have to recompile (!) MySQL to change the stopwords list. Me hates MySQL!
As the sysadmins running the site will never, ever recompile MySQL (they also turned down switching from 5.6.something to 5.8.something because that might break some of the other apps (done in Java) running on the server...), my only options seems to hardcode a workaround into the app ($search='konsumentenmagazin' if $search == 'help').
Sigh...
My only hope for the future is that they issue a company guideline to not name any new radio programmes after a MySQL stopword.
Original: http://use.perl.org/~domm/journal/29217
as long as you are using a release later than 4.0.10, the stopword list can be configured by pointing it at a text file to use (or disabled entirely). you'll need to rebuild the index after changing the stopword list.
http://dev.mysql.com/doc/refman/4.1/en/fulltext-fine-tuning.html [mysql.com]
Oh, thanks for the hint. As the server is running 4.0.15, this might be an option. I'll only have to convince the sysadmins...
... on Atom!