start of new DB design
Maximilian Kossick
mkossick at gmx.de
Wed Jun 6 23:09:40 CEST 2007
On Wednesday 06 June 2007, Ian Monroe wrote:
> On 6/6/07, Maximilian Kossick <mkossick at gmx.de> wrote:
> > And another idea: you could remove the distinction between trackid and
> > externalid in the table if you'd just store the urls (as returned by
> > Track::url(). The method is designed for cases like this. ) in the table.
> > That way we could easily handle multiple SQL collections (i'm not sure if
> > we want to add this functionality) and it would make the code a lot
> > easier. As pseudo-code:
> >
> > load all urls from the current playlist table
> > for each url
> > {
> > call CollectionManager:::trackForUrl
> > if result of trackForUrl != 0
> > insert track into playlist
> > else
> > create and insert proxy
> > }
>
> I'm worried that this wouldn't be fast enough. Currently in the XML
> file we store all the metadata information, so it doesn't have to read
> any tags to load the playlist. Its important that the playlist loads
> fast since its part of the initial application load time.
>
> This would certainly be a lot easier though.
We could always use the proxy class when loading the playlist, and defer
checking for the actual track in the proxy using QTimer::singleShot with a
timeout of 0. but no song in the playlist would be playable until the slots
in the proxys are executed and each proxy in the playlist checks for the real
track.
This approach would work for all track implementations that don't need to be
downcast (like LastFm::Track to be able to access the last.fm specific
methods, and probably podcast tracks), but i think i could write a proxy for
those implementations too, if necessary. I'm not sure if it would actually be
faster, but its advantage is that it would work regardless of the actual
track implementation.
> Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070606/65cd086d/attachment.pgp
More information about the Amarok-devel
mailing list