proposed solution for defects 90095 & 119539 (674 votes, 638 votes) (Multiple artists per song)

Jeff Mitchell kde-dev at emailgoeshere.com
Sat Aug 30 20:38:12 CEST 2008


On Thursday 28 August 2008 07:51:54 Devon Jones wrote:
> I talked with a number of devs on the irc channel, and asked them about
> these bugs, and essentially they said that 2.0 will freeze the database
> schema for future releases, and there is presently no plan to allow for
> anything more then the present 1 artist and 1 composer per track.

Probably for 2.0 releases, at least, not 2.x where x >= 1.

Really, we can modify the schema whenever we decide it's necessary.  Because 
we'll be standardized on one type of database (hopefully mysqle) it will make 
it far easier than 1.x in that regard.  But it requires being very careful, 
and every time you want to make a change, the list of things that need to be 
changed from 2.0 get longer and longer.  So don't think that we can never make 
crucial changes to the database, but they are likely to wait for minor 
releases instead of point releases, and we're likely to try to make changes 
all at once.

One other note:  I think for A2 we should make a habit of creating a copy of 
the user's collection file -- easy if it's embedded, i.e. sqlite or mysqle -- 
every time we run the database updating function.  If we cannot make that 
copy, we should not continue with the upgrade; also, this way, if a user says 
that the upgrade toasted their collection, they'll have a backup to work from 
to try to figure out what's going wrong.

--Jeff


More information about the Amarok-devel mailing list