< Amarok | Archives Amarok Playlist Re-design the idea is to redesign amarok to use sql(instead of xml) for playlists because of speed and memory problems: advantages: "filling" of playlists will be a lot faster faster searching in playlists faster sorting of tracks in playlists less memory usage(playlist does not consist of objects and is only partly stored in memory - cursor in sql: see qdatatable documentation in trolltech qt documentation) less data redundancy if playlist items are also in collection database disadvantages: if e.g. a track is removed in the collection db, the track(id) needs also be removed out of the playlist(but same work is done for the album, year, artist and statistic tables) a lot coding work to do(some developers believe that this unnecessary because it's "braindead" if you have a playlist with more than 100 items) how to realize it: write the playlist stuff so that it runs with sql write a new import dialog for playlist(import tracks also into collectiondb: yes(=>table content) or no(=>table content_nodb) - other possible solution in "additional ideas" - or combination of both ideas?? switch from qlistview to qdatatable and qdataview cleanup old sql stuff(why rebuilding the db when only one track is removed?) additional ideas: playlist can have pictures for easier recognizing(key: "picture") it's also possible to have a playlist with tracks which are in the collectiondb and tracks which are not in it(no "in_collectiondb" key in the playlist_names table and tracks in both other playlist tables) tables in sql: playlist: name id in_collectiondb picture the different modes (e.g. "partymode") playlist_tracks: playlistid trackid queue playlist_tracks_nodb: url createdate album artist title length bitrate score queue Retrieved from "https://community.kde.org/index.php?title=Amarok/Archives/Proposals/Playlist_SQL_backend&oldid=28088" This page was last edited on 14 December 2012, at 11:00. Content is available under Creative Commons License SA 4.0 unless otherwise noted.