History talk:Next Generation Schema/Release Editor: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
No edit summary
 
(One intermediate revision by one other user not shown)
Line 17: Line 17:
## If one release, duplicate the tracklist and re-use all but one of the tracks. Create a new track and connect to new tracklist.
## If one release, duplicate the tracklist and re-use all but one of the tracks. Create a new track and connect to new tracklist.
## If update all releases, update only the track.
## If update all releases, update only the track.

==Problematic Cases==
* Editing a track title/artist.
** If the edit effects only a single row (ie, one-to-one) - then we just accept the changes outright
** Otherwise, we check the edit distance of what they entered to what it used to be. A question is prompted to allow the user to break/keep the link to the recording. If it is over some threshold, we default to breaking the link (and possibly change the question a bit)

Latest revision as of 16:21, 4 November 2011

Proposed data change workflow

'This section is still work in progress' --RobertKaye 23:53, 8 July 2009 (UTC)


In trying to understand and solve the open questions for the release editor I think I can see the following data change workflow emerging. This workflow should be applicable to all of the levels of data we have.

For a given data field that links to other tables, (e.g. track name) after the user makes a change, check to see what effects this change would have. If the field does not have dependent data (e.g. this change would affect only one row in each of the linked tables), accept the change and allow the user to go on.

If the field has dependent data, show the impact this change will have. (I would hope that the user would rather pick out an alternative that already exists over making a new change -- lets bank on this laziness and make it easier to chose a correct thing that to make a new one.) If the user insists on making the change, duplicate the data, make the changes to the duplicated data and update the links that should point to the new data.

Example -- change a track name:

  1. User changes the name of a track that is used on 3 releases.
  2. Show the user the three releases that use this track, so that the user can see the impact of their changes.
  3. Let the user choose between changing one release or all 3 releases:
    1. If one release, duplicate the tracklist and re-use all but one of the tracks. Create a new track and connect to new tracklist.
    2. If update all releases, update only the track.

Problematic Cases

  • Editing a track title/artist.
    • If the edit effects only a single row (ie, one-to-one) - then we just accept the changes outright
    • Otherwise, we check the edit distance of what they entered to what it used to be. A question is prompted to allow the user to break/keep the link to the recording. If it is over some threshold, we default to breaking the link (and possibly change the question a bit)