History talk:Next Generation Schema/Release Editor: Difference between revisions
No edit summary |
Reosarevok (talk | contribs) m (Talk:Next Generation Schema/Release Editor moved to History talk:Next Generation Schema/Release Editor) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
==Proposed data change workflow== |
|||
Open questions about the schema: |
|||
''''This section is still work in progress'''' --[[User:RobertKaye|RobertKaye]] 23:53, 8 July 2009 (UTC) |
|||
* Why do we have a table called track and a table called recording? What purpose do they serve? |
|||
** I think the [[Next_Generation_Schema#Track|NGS]] page explains it well. [[User:LukasLalinsky|Lukáš Lalinský]] 19:45, 7 July 2009 (UTC) |
|||
* Why does the recording table have an artist_credit that is not an FK and track does as well, but there its not an FK? Is this a graph error? |
|||
** Error in the diagram, it's fixed now. [[User:LukasLalinsky|Lukáš Lalinský]] 19:45, 7 July 2009 (UTC) |
|||
* Why do both recording and track have an artist_credit and name? |
|||
** Because that's what humans tend to use as identifiers. :) They normally wouldn't know "b98ee5f2-0b07-4da6-913c-acfe19d4578d", but they mostly likely do know what "Thriller by Michael Jackson" is. That's for recordings. I think it's obvious why tracks need to have artist credits and names. [[User:LukasLalinsky|Lukáš Lalinský]] 19:45, 7 July 2009 (UTC) |
|||
(Can we please move this discussion to [[Talk:Next Generation Schema]]? [[User:LukasLalinsky|Lukáš Lalinský]] 19:45, 7 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: |
|||
# User changes the name of a track that is used on 3 releases. |
|||
# Show the user the three releases that use this track, so that the user can see the impact of their changes. |
|||
# Let the user choose between changing one release or all 3 releases: |
|||
## 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. |
|||
==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:
- User changes the name of a track that is used on 3 releases.
- Show the user the three releases that use this track, so that the user can see the impact of their changes.
- Let the user choose between changing one release or all 3 releases:
- 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.
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)
