proposed solution for defects 90095 & 119539 (674 votes, 638 votes) (Multiple artists per song)
lfranchi at kde.org
Thu Aug 28 17:07:09 CEST 2008
> My proposal:
> Since you want to nail down the schema more or less permanently for
> (at least that was what was said on irc) I propose the following
> 1) remove artist and composer columns from the track table
> 2) create a track_contributor table
> CREATE TABLE track_contributor (
> id INTEGER PRIMARY KEY,
> artist INTEGER,
> track INTEGER,
> contributor_type VARCHAR(255)
> 3) Alter the code to store both artist and composer in this table, and
> alter anything that reads from track to get the artist and composer
> this table. Contributor_type would be used to label the type of
> such as "Artist" or "Composer" today, and things like
> "Remixer" (TPE4),
> "Album Artist" (TPE1 normally), "Orchestra" (TPE2), "Lyricist" (TEXT),
> "Original Performer" (TOPE), etc.. in future releases.
This is one of those features that we get a lot of requests for
because it is usually desired by a *very* vocal minority. At the same
time, none of us devs have huge well-tagged classical libraries, so we
haven't implemented this ourselves.
I do support the modification of our DB schema right now, as long as
we do it *really soon* (e.g. next 5 or so days). I think we should
really do our best to freeze the 2.0 schema, to reduce any sort of
complexity on the part of the user with upgrading, downgrading, etc
(the 1.x series were kind of a PITA in that department).
That said, I don't think any of us are too engaged in this feature, so
you would have to
a) be willing to put in the work now, pre-2.0, to modify the schema a
b) be willing to maintain it over a longer-term sort of timeframe.
everyone: thoughts? comments?
i think this could also be a really cool feature that yet again
distinguishes us from most other players.
> Nothing else in 2.0 so as to not add any more risk to the schedule.
> 2.0 + (2.1, 2.01, not sure what meaning you assign to your version
> < snipped >
> I think that about covers it.
> I'm willing to pitch in and do the work, but this represents definite
> change in your app, and I know that I'm totally new to the community.
I think just changing the schema pre-2.0 isn't too invasive, and
isn't a feature-addition in itself. Nevertheless, it is important
groundwork for the future 1-N stuff you are talking about.
Leo Franchi (650) 704 3680
Tufts University 2010
lfranchi at kde.org
leonardo.franchi at tufts.edu
More information about the Amarok-devel