Issue Details (XML | Word | Printable)

Key: MBS-2936
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Oliver Charles
Reporter: tele
Votes: 1
Watchers: 1

If you were logged in you would be able to see more operations.
MusicBrainz Server

Merging Artists does not merge birthday

Created: 30/Jun/11 05:28 PM   Updated: 03/Oct/11 11:24 AM   Resolved: 03/Oct/11 11:24 AM
Component/s: Edit system
Affects Version/s: None
Fix Version/s: Bug fixes, 2011-09-26

 Description  « Hide

Tina Dickow the target had no birthday entered.
Tina Dico did. (entered before merge)

Merger resulted in birthday not appearing under Tina Dickow.

Gender, Country & Date entered after merge.

Sort Order: Ascending order - Click to sort in descending order
Oliver Charles added a comment - 18/Jul/11 01:25 PM

There's a bit of a problem with this, take the following:

Name Year Month Day
Artist A 2010 02  
Artist B 2011 05  
Artist C   02 20

It's a contrived example, but assume people want to merge these 3 artists together, all into Artist A. What should the begin date be? 2010-02? 2010-05? 2011-05-20? 2011-02-20?

Oliver Charles added a comment - 02/Aug/11 09:43 AM

Decision required: how should we handle this merge?

Johannes Weißl added a comment - 02/Aug/11 10:29 AM

I wouldn't do it too complicated (because every merge strategy might be counter-intuitive to some). My proposal is:

  • if the target has no column (day/month/year) filled in at all, take the one of the merged entity
  • in all other cases, do not merge at all

The reason is, in 99.99% of the cases I've seen, we always merge a wrong (bogus/duplicated) artist into the correct one. Since it is wrong, I wouldn't trust the date at all.

Oliver Charles added a comment - 02/Aug/11 10:58 AM

A merge is still multiple old-entities. In the above example, merge A&B into C. What should the year be? The problem is that when we consider the date as an atomic value, there is a conflict. (This is true for other data, such as merging the artist type).

Robert Kaye added a comment - 22/Aug/11 09:38 PM

What if we checked for this case and alerted the user that there is a conflict? We could prevent the merge until the birthdays have been fixed up. How does that sound?

Johannes Weißl added a comment - 23/Aug/11 09:34 AM

Hmm, I don't think that's a good idea... that means normal users will have to wait 4 weeks to merge artists where one has a bogus date. I think the best option still is to only update the birthday of the merged-into artist ("C" in the example), if it is completely empty. If so, the most "complete' (or a random if both have the same completeness) one of "A" and "B" should be used.

For example, I have a bogus artist with year "2000-01-01" (because that was the day he started performing, people sometimes confuse this), and I merge it into the correct artist with birth date "1982" (nothing more known), I certainly not want "01-01" appended to the year.

Merged artists are almost always mistakes created by some careless editors, the information shouldn't be rated to high.

Oliver Charles added a comment - 23/Aug/11 09:58 AM

A decision has not been reached here yet, I agree more with hrglgrmpf here - blocking merging is not a way to go.

Robert Kaye added a comment - 19/Sep/11 06:36 PM

I agree with hhgfhgmrmghfpf. Lets go with:

  • if the target has no column (day/month/year) filled in at all, take the one of the merged entity
  • in all other cases, do not merge at all

I'll add the one step that if no merge happens, ModBot should leave a note on the edit that states all of the old dates that could've been merged and tell that no date has been merged. This allows the editor to go in an manually set a date from the data preserved in the edit note.

Oliver Charles added a comment - 23/Sep/11 12:48 PM

I believe there's a sensible merge strategy now. This in review at and available for testing at