Bugzilla – Bug 2625
Enhancement request for 'custom search' columns within the SlimServer database
Last modified: 2009-09-08 09:24:59 UTC
I am the author of the Lazy Search Music plugin for SlimServer 6.2 and later (see http://hickinbottom.demon.co.uk/slimserver/lazy-searching/lazy-searching2.htm for full details). This plugin is working quite well now, and I've had positive feedback from a number of people. I've had a number of problems with it, however, that have been due to the way that the plugin hijacks the 'search' text columns for albums, contributors, tracks and genres to add the approximate 'lazy search' versions to the database without requiring people to patch their schemas. I've been able to add increasingly complex workarounds for those problems to date, but I've now come to a brick wall where I'll not be able to support the plugin on SlimServer 6.2 any longer. The enhancement I'm requesting is the addition of a single new 'customsearch' column to each of the 'albums', 'contributors', 'tracks' and 'genres' tables. This would be of the same type as the current 'titlesearch/namesearch' columns that are already there, and would be indexed. Their default contents would be NULL. Along with the database modifications (for both MySQL and SQLite), changes would be needed DBI classes to access these new columns. I wouldn't expect the core SlimServer software to do anything with these columns at all (other than make them available through the DBI classes), but it would have them so that a plugin could make use of them if it desired (I've written one such search enhancement plugin, but perhaps other ones are possible too � of course, a user could only ever use one such plugin at a time). I've suggested 'customsearch' as the column name to avoid being specific for my plugin. In order for me to support SlimServer 6.2 I'd like this enhancement made to the 6.2 branch if possible. I'd hope that this was a pretty low-risk change given that the core SlimServer will not use these columns and they will be empty (or NULL) by default. To make this as easy (and likely!) as possible I'm quite happy to provide a candidate patch against SlimServer 6.2.x or 6.5, but I'd like the go-ahead from somebody with commit rights before I do that work. I'll make sure the patch modifies all the necessary parts (including both MySQL and SQLite schemas), and I'll test it on both database types. Suggestions of alternatives to these columns are welcome, but I've been unable to think of an easy alternative. Thanks.
well, the ruling so far has been 'no new features' for 6.2.x. I'm against the idea of users setting the target in a bug report. It should be for the assigned person or the project leaders to set targets. anything else just leads to the opportunity to confuse things even with the best of intentions. If you have a patch to accomplish what you want, please provide it. If such a patch is not readily available, then this really shouln't be marked for 6.2.2 at all. I'll leave this for Dean/Dan to make the call.
I'd like Dan to weigh in on the risks in adding this to the 6.2 tree.
This change isn't suited for 6.2 It requires a schema change, and unfortuantely for SQLite, there's no ALTER TABLE ADD COLUMN. So that means a rebuild of the database. Stuart - I'm curious to know why your plugin needs to modify the data in the db for it to work.
Apologies if setting the target was the wrong thing to do - I'm used to being ordered to fill in as much detail as possible on new bugs at work. I'm quite happy for you guys to push it to whatever release you want, of course. I store encoded versions of the artist/track/genre and album names in the database to facilitate easy and fast searching. It actually works quite simply - the encoded version is the numeric remote control buttons that have the corresponding characters. An example is "STONES", which is encoded to "786637". Once you have that, when the user enters the lazy search "786637" (although he thinks he's choosing the letters on the remote), searching is trivially easy. With a database that supports regular expression searches you could use the existing 'search' column with a regex like "(P|Q|R|S)(T|U|V)(M|N|O)(M|N|O)(D|E|F)(P|Q|R|S)", but apart from that being slower to search (I'm guessing, as it's not a simple index search), such regexes aren't possible with SQLite (I don't believe). If you're comfortable with the idea I'll work up the change as a patch against 6.5. Just post to this bug and I'll get on with it. Alternatively, you might have a bright idea for using what's currently in the database as you understand what the DBI classes can do far better than I. Thanks again, Stuart
Created attachment 1052 [details] Patch to add 'customsearch' columns and DBI attributes, for MySQL and SQLite Attached is a patch that adds these columns to SlimServer 6.5 (r5304).
Commited in change 5843.
That's great news - thanks very much. I'll try to get the plugin migrated to this new schema at the weekend then I'll post back to this bug with the outcome. Thanks again.