>With every album having an album artist(s), it also makes it very simple >to implement 'Browse Album Artists'. > I agree, it's a teeny bit easier to have ca.role = 5, instead of ca.role IN (1,5) and ignoring artists that are on compilations. It's cleaner, easier to understand.
The equivalent query for the current release isn't too bad though: SELECT DISTINCT ca.contributor, CAST(c.name AS CHAR) AS album_artist FROM contributor_album ca JOIN albums a ON a.id = ca.album AND a.compilation IS NULL JOIN contributors c ON c.id = ca.contributor WHERE ca.role IN (1, 5) ORDER BY c.namesort with roles 2,3,4 to be added if you want band, composer and conductors in the list too. Query execution time is practically the same for me (both less than 10ms). For consideration: 1) there would be more rows to write in the DB at scan time (at least another contributor_album row per album). 2) in SBS, adding an album artist per album would break artist navigation for me, as navigating artist links also included the role. This is okay now in LMS, that doesn't include the role in the artist navigation links. But some people don't like that. >If you want to have the VA artist bubble to the top, as it's done now >in Browse Artists, all you need to do is manipulate its namesort column >in the contributors table. It's not Album Artist=Various Artists that gets put on the top, it's a fixed entry called "Various Artists", that has all Compilations. i.e. not a query to return album artist contributors, but a query to return albums where compilation=1. So, a browse mode for album artists should just return a straight list of album artists, ordered in artist name order, just as your query has it. "Various Artitsts" would just be a normal artist, sorted under V. _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
