Merge Rather Than Delete: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
m (1 revision(s)) |
|||
Line 1: | Line 1: | ||
=Merge Rather than Delete Duplicate Releases= |
==Merge Rather than Delete Duplicate Releases== |
||
It's usually best to enter [[Merge Releases Edit|MergeReleasesEdit]]<code><nowiki></nowiki></code>s to deal with [[Duplicate Release|DuplicateRelease]]<code><nowiki></nowiki></code>s instead of entering [[Remove Release Edit|RemoveReleaseEdit]]<code><nowiki></nowiki></code>s. |
It's usually best to enter [[Merge Releases Edit|MergeReleasesEdit]]<code><nowiki></nowiki></code>s to deal with [[Duplicate Release|DuplicateRelease]]<code><nowiki></nowiki></code>s instead of entering [[Remove Release Edit|RemoveReleaseEdit]]<code><nowiki></nowiki></code>s. |
Revision as of 06:41, 17 April 2009
Merge Rather than Delete Duplicate Releases
It's usually best to enter MergeReleasesEdits to deal with DuplicateRelease
s instead of entering RemoveReleaseEdit
s.
Deleting releases has two kinds of bad effects on the database:
- The MusicBrainzIdentifier
s that have been referenced anywhere (tagged files, links to MusicBrainz from other sites) will become invalid when the item is deleted. When merging it, however, the old MusicBrainzIdentifier
s will forward to the new item.
- Even if there's no useful data (DiscIDs, PUIDs, ReleaseEvent
s) attached to the release, it's possible that someone may enter a AddPUIDsEdit, AddDiscIDEdit or EditReleaseEventsEdit before your RemoveReleaseEdit is approved. If so, the recently added data will be lost.
This MergeRatherThanDelete guideline also applies to artists, but since a RemoveArtistEdit is not possible for an artist with any releases, relationships, tracks or NonAlbumTracks it is more of a system-enforced rule than a guideline. An analogous guideline is to MergeMisspelledArtists.
However, pay close attention to DeleteRatherThanMerge when dealing with the common "feat artist" problem.
- And which problem would that be? --Keschte