History talk:Next Generation Schema/Release Editor

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.