gSoC Implement a better database schema

[Ian Monroe]

On Thu, Mar 26, 2009 at 7:06 AM, Caleb Cushing <xenoterracide at gmail.com> wrote:
> 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.

Heh porting Amarok to akonadi is kind of a silly way to solve the
-fPic issue. Fedora solved it by simply issuing a custom GCC command
to link mysql embedded as a shared library.

One thing I have seriously thought about was using Soprano and a
semantic SPARQL database instead of SQL, like Akonadi plans to do. I'm
hoping that I get to use SPARQL in my job so I can see if its good for
us. From the little I know about it, it might make more sense.

Ian