Amarok/Archives/Proposals/Playlist SQL backend

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