Bugzilla – Bug 7210
Add support for multiple searches being performed in the database scheme URLs
Last modified: 2009-09-08 09:15:18 UTC
Description: This is a simple patch, as part of the progress towards being able to record favourites for any search. At present the form of the db scheme is 'db:<table>.<field>=<value>'. This is very restrictive and obviously fails if you were to use 'db:Album.title=No Album'. My proposed change is to allow multiple search requests, in the form 'db:<request>{&<request>}'. For example: 'db:Contributor.titlesearch=Madonna' would still be valid. 'db:Contributor.titlesearch=Madonna&Album.namesearch=No Album' would also be valid. 'db:Contributor.titlesearch=Madonna&Album.namesearch=No Album&Year.id=1990' would be similarly valid. Any values in the <value> section should be URL escaped as normal - particularly the & must be escaped. Implementation: First we detect the db scheme and that it has a reasonable shape (<x>.<y>=<z>). Having found this, we split the terms at the '&' character. For each one we accumulate a hash of the class name and the object resolved from that class name. No error checking is performed here (in line with the single entry implementation). If it does not match the db request type then it's a track or playlist search and we manually populate a hash to contain the appropriate entries. Finally, rather than processing just a single entry and passing the terms to the 'parseSearchTerms' function, we process each one and construct the search terms string. Then we call the parseSearchTerms function as previously. Testing: Add a favourite somewhere. Find the web interface entry for it. Edit the url item for that favourite to change it from a single search to a multiple search. The example I'm using for testing here is: db:album.titlesearch=No Album&contributor.namesearch=Madonna which only queues and plays those un-albumed tracks by Madonna.
Created attachment 2910 [details] Patch for Slim/Control/Commands.pm for multiple db: scheme queries
Andy, what do you think of this patch?
Your patch looks good, but we also need a way to save favorites in this format, right? Were you planning on working on that as well?
I planned on going through the relevant sections of the code and updating the db: URLs where necessary to add in the extra information. Ie get the back end functionality in, then add the code to use it, so that the changes can be reviewed more easily. I'm a big fan of small, constrained changes that can be tested carefully, rather than large changes that are hard to review and may have side effects because of that.
Well my only issue is that the current patch here doesn't benefit anyone because there's no way to use it (or test it) other than hacking together your own db URL.
Trying it with the explicit database URLs is part of the testing though. The other part of the testing is to ensure that the existing use is not compromised by this change. The benefit is that the functionality is present. Once the functionality is present, then we go on to using it more fully. The alternative is that you provide the low level functionality and all the changes that should use it all in one patch. Given that the low level change can be made with zero-impact on the rest of the system isn't a problem, it's the point of isolating the change. Small, incremental changes, tested along the way to show that no regressions have been observed. It may be that you employ a different development methodology to this, then I can accommodate that, but I don't like doing development in that way myself and so presented the simple change.
Patch applied in 7.1 change 21304.
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC