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

From MusicBrainz Wiki
Jump to navigationJump to search
(Removing all content from page)
Line 1: Line 1:
  +
=Proposed data change workflow=
  +
  +
''''This section is still work in progress'''' --[[User:RobertKaye|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 (e.g. changing one track name that is linked from 5 releases), show possible alternatives. (e.g. show other track lists from this release (group)). 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, accept the changes and update links appropriately. (the last sentence needs much more thought)

Revision as of 23:53, 8 July 2009

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 (e.g. changing one track name that is linked from 5 releases), show possible alternatives. (e.g. show other track lists from this release (group)). 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, accept the changes and update links appropriately. (the last sentence needs much more thought)