Urls in tables

[Maximilian Kossick]

On Thu, Aug 21, 2008 at 6:34 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Wed, Aug 20, 2008 at 5:35 PM, Jeff Mitchell
> <kde-dev at emailgoeshere.com> wrote:
>> Max, Mark, Leo, Seb, etc...
>>
>> Please take a look at this thread and give your thoughts.  I'd like to
>> get this resolved soon, as the sooner database changes can be made, the
>> better.
>>
>> Thanks,
>> Jeff
>
> Does anyone understand the lifecycle of the URL table?
>
> In Amarok 1.4 we used URLs as the "foreign key" (and then device stuff
> later). The idea of having the URL table was to simplify the DB
> schema. But it should essentially make the URL table a permanent
> table, not something to be dropped with every rescan. I don't really
> understand how the stuff works now.
>
> Ian
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
Unlike Amarok 1, we now have the possibility to control where we want
to store permanent data (statistics, lyrics and whatnot) depending on
the source of the music. We can live with sqlcollection storing its
data in the statistics, and other statistics stored somewhere else.
Statistics will be copied to the correct table when files are
copied/moved within A2. If we really want to support the use case
mentioned in this thread (removing a collection dir but not removing
the files) we can figure out some kind of service to move statistics
from one collection to another if we think that the file is the same
(what happened to that syncing framework btw?). But that's hardly a
release blocker.

The decision whether to use a central table to store the statistics of
*all* collections that do not have a special storage location (e.g.
ipod, nepomuk) is one that should be made before the release of A2.
But we should probably discuss that in a new thread, because the
approach implied by this thread's title would be wrong in that case.

Max