Last Update Feature: Difference between revisions
(+ discid (Imported from MoinMoin)) |
RobertKaye (talk | contribs) (Remove update rules that didn't pan out. :-( (Imported from MoinMoin)) |
||
| Line 8: | Line 8: | ||
Not all of these features will be implemented immediately. For the next release I foresee doing the first two items above. |
Not all of these features will be implemented immediately. For the next release I foresee doing the first two items above. |
||
Originally we had planned to have the update rules change other related data items. For instance, updating a release would also cause the artist and the label associated with the release to be updated. However, our database server buckled under the load to constantly update all of this information so we were forced to abandon this approach and not have '''any''' cascading updates happen. |
|||
When an entity (artist, release, track, or release event) in the database changes it should update the some related entities. What entities should propagate changes to other entities was a subject of much discussion. Poorly planned update rules could cause avalanche effects where one change could update nearly the whole database. To reach a compromise of too many updates and not enough updates we decided to never recursively propagate changes and we decided to not keep a last update field for tracks. When a track is updated, the update field for the releases it belongs to are updated, which we believe will give enough information to our users about what data changed. |
|||
The feature as it stands now only updates one data entity at a time. So, if a release is edited the artist nor its associated labels will be updated. |
|||
==Database changes== |
==Database changes== |
||
For this feature we added new tables: artist_meta, label_meta. These tables only contain an id column (with a foreign key to the artist/label tables) and a lastupdate timestamp. For releases (albums in DB speak) we added the lastupdate column to the albummeta table. (I can't wait to get the naming in the DB normalized). |
For this feature we added new tables: artist_meta, label_meta. These tables only contain an id column (with a foreign key to the artist/label tables) and a lastupdate timestamp. For releases (albums in DB speak) we added the lastupdate column to the albummeta table. (I can't wait to get the naming in the DB normalized). |
||
==Update rules== |
|||
If an artist is changed, then update: |
|||
* releases (including VA releases). For each of these releases, update the related: |
|||
** labels |
|||
** artists (excluding the original artist) |
|||
If a release is changed, then update the related: |
|||
* labels |
|||
* artists |
|||
If a label is changed, then update the related: |
|||
* releases. For each release, update the related: |
|||
** labels (excluding the original label) |
|||
** artists |
|||
If a track is changed, then update the related: |
|||
* releases. For each release, update the related: |
|||
** labels |
|||
** artists (all track artists for VA releases) |
|||
If release event is changed, then update the related: |
|||
* releases. For each release, update the related: |
|||
** labels |
|||
** artists |
|||
If discid is changed, then update the related: |
|||
* releases. For each release, update the related: |
|||
** labels |
|||
** artists |
|||
Remember, only those updates shown above are made. The changes are never recursive. |
|||
[[Category:To Be Reviewed]] [[Category:Development]] |
[[Category:To Be Reviewed]] [[Category:Development]] |
||
Revision as of 00:54, 22 January 2009
Last Update database extension
This feature keeps track of when data in the database last changed. Changed, in this case could be any update to the database. It could be an edit that changes something important like the name or just the count of how many edits are open for this artist. This feature is designed to allow us to add the following features to MusicBrainz:
- "Artist was last updated X days ago" display in the server.
- RSS feeds for artists, albums and labels. You could subscribe to feeds of your artists and see changes being made to their data in MB.
- HTTP caching, which would allow us to let Google index the site without costing us a lot of bandwidth.
Not all of these features will be implemented immediately. For the next release I foresee doing the first two items above.
Originally we had planned to have the update rules change other related data items. For instance, updating a release would also cause the artist and the label associated with the release to be updated. However, our database server buckled under the load to constantly update all of this information so we were forced to abandon this approach and not have any cascading updates happen.
The feature as it stands now only updates one data entity at a time. So, if a release is edited the artist nor its associated labels will be updated.
Database changes
For this feature we added new tables: artist_meta, label_meta. These tables only contain an id column (with a foreign key to the artist/label tables) and a lastupdate timestamp. For releases (albums in DB speak) we added the lastupdate column to the albummeta table. (I can't wait to get the naming in the DB normalized).
