gSoC Implement a better database schema

[Caleb Cushing]

On Thu, Mar 26, 2009 at 3:40 AM, Jeff Mitchell <mitchell at kde.org> wrote:
> So, of course, if you implement such a feature, you will support postgres
> from here to eternity?

to paraphrase the movie starship troopers, I'm it until I'm dead or I
find a better music player/database.

> Amarok 1 saw a lot of releases with very buggy postfix

when did amarok get email support ;) sorry yeah I hear you.

> You're assuming the schema needs to be rewritten.  I've not heard a
> compelling argument why, and have heard compelling reasons why not.

an example is the years table. what happens when I change the year
2008, to 1994? all the tracks listed as 2008 show as 1994? this table
should be dropped and the year column should be moved to the tracks
column. If we could rely on user data being reliable and consistent,
it would be even better in the albums table, unfortunately we can't
rely on users to actually have both album/year populated consistently.

to be honest I think my suggestion is a lost cause, and yet it's
caused me to think of something else I was thinking about.

akonadi is meant to be an implementation agnostic data store, is it
not? I'm not sure how it works (api or anything) but it might we
worthwhile to migrate to, kinda like amarok 2 migrated to phonon
instead of doing it's own sound engine management. This would actually
also solve the fPIC issue because akonadi doesn't do it that way...
I've also heard there supposed to be a project to support postgres in
akonadi. perhaps this would be a more worthwhile project.
-- 
Caleb Cushing

http://xenoterracide.blogspot.com