Bug 135667

Version:            (using KDE Devel)
Installed from:    Compiled sources

As I was saying in my recent post on the list, storing the playlist and undo information in XML is a major source
of slowdowns currently; database storage would allow faster operation, incremental updates, as well as interesting future applications like correlating with the tags db.

The idea met with approval, so I'd like to start working on this. To get some dev support, and to avoid prototyping in completely the wrong direction, I'd like to use this bug to get a discussion started.

The design I have in mind unifies incremental playlist saving, and undo/redo in a single structure that works like a log. These two aspects are both related to the evolution of the playlist over time, so I think this makes sense.

I wrote the SQL for creating the new tables and indices, and fount it most convenient to outline the meaning of the tables,  and the operations they support, inside the SQL as comments. I will attach the file after creating the bug. Feel free to comment on it, propose changes, apply to your db to make sure it works, etc.

I am not sure whether we should use the existing collection.db, or create a new database. The name collection.db suggests that the playlist does not belong there, however it is simpler to have a single db, and it will also allow joins with the tag tables, if it becomes useful in the future. Please advise :)