Urls in tables

[Jeff Mitchell]

On Wednesday 13 August 2008, Ian Monroe wrote:
> On Wed, Aug 13, 2008 at 6:40 AM, Jeff Mitchell
> <kde-dev at emailgoeshere.com> wrote:
> [snip]
>
> > But that prompted Ian to have a thought as to whether the url table
> > itself, currently a very sqlcollection-based table built by the
> > collectionscanner, should have support for adding entries from outside
> > the collectionscanner. Here are his thoughts from last night; he can
> > respond to this with more detail if people are interested:
> >
> > [23:17:02] <eeanm> jefferai: seems like the best solution is to make
> > "being in the collection" not a requirement for the URL table
> > [23:18:01] <eeanm> might be a bit late to do that for now though
> > [23:18:05] <jefferai> what do you mean?
> > [23:18:18] <jefferai> the url table is built by the collection scanner
> > [23:22:59] <eeanm> jefferai: What I'm saying is that the collection
> > scanner could be just one possible source for a new row in the table
> > [23:23:04] <eeanm> in the url table
> >
> > Anyways, we decided that it's a good time to send it all over there while
> > you all are together...
>
> Basically it would be really handy to the db schema if instead of
> having the columns urlid (for when the track is in the collection,
> this way its automatically linked to stats and to AFT updates) and a
> full_url (for when a track isn't or is no longer in the database; for
> instance keep track of stats of streams or for playlists where the
> included tracks could potentional start in the collection but then
> fall out of it) in all sorts of tables like lyrics, statistics,
> playlists that there would *always* be a urlid for any track from
> anywhere. So if you play a file thats not in your collection, it would
> get added to the url table and statistics recorded for it.

I could see this working if the dir value were empty for these entries to that 
updates to the sqlcollection could still remove tracks by dir as necessary.

> Not sure how hard that is to implement, since the URL table is
> probably current wiped out. So probably a Amarok 2.1 change even. But
> would be interested to know what people more familiar with the code
> think.

I think getting the db schema as right as we possibly can before releasing 2.0 
will prevent many headaches later.

--Jeff