optimization proposal -- playlist stored in the DB

[Seb Ruiz]

On 06/10/06, Maximilian Kossick <mkossick at gmx.de> wrote:
> On Friday, 6. October 2006 09:41, Ovidiu Gheorghioiu wrote:
> > Hi guys,
> >
> SNIP
> >
> > I think having the playlist in the DB would eliminate these issues.
> > Loading would definitely be faster, as can be seen from the smart
> > playlist loading time (1.1%in SqlLoader) -- and the smart playlist is
> > actually a fairly complicated query. Saving will likely be much faster
> > too, and most importantly it can be done incrementally for things like
> > undo or autosave.
>
> I agree.
>
> > And there are other fringe benefits, too. For example, another 6% was
> > spend loading song ratings one by one as I was scrolling, on the first
> > instance of the playlist which came from XML -- these can probably be
> > stored right in the playlist table.
>
> That can be solved relatively easily by not lazy loading the song scores and
> ratings. At the moment, CollectionDB only loads the actual song tags when
> creating a new MetaBundle. It should be possible to add a join on the
> statistics table and read the song score and rating without a performance
> hit. The song scores and ratings are stored in XML when they are available,
> too.
>
> > So, what do you guys think? I'd be willing to do a significant amount
> > of the work, but I would likey need / use some help from somebody
> > who's familiar with the DB. And also some testing on the other two
> > db's, which I don't have installed or configured.
>
> Ask here or (better) in our IRC channel. It should be possible for you to
> stick to standard SQL which works on all supported databases. Somebody will
> usually complain in #amarok within a few minutes of your commit if the SQL is
> broken;)
>


On the same not, how about keeping the undo/redo stack and the
current.xml playlist inside the database?

-- 
http://www.sebruiz.net/