Urls in tables

Jeff Mitchell kde-dev at emailgoeshere.com
Thu Aug 21 22:55:56 CEST 2008


Maximilian Kossick wrote:
> 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.

The thread's title doesn't imply any approach.  It's asking why some
tables use a "url" field to imply an integer reference to the url table,
and some tables use a url field to imply a string path (not url).


More information about the Amarok-devel mailing list