Uploaded image for project: 'MusicBrainz Server'
  1. MusicBrainz Server
  2. MBS-7676

When band member credited with multiple instruments, db creates multiple relationships, one for each instrument, instead of just one relationship for all the instruments

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Normal Normal
    • None
    • None
    • None
    • None

      For example if a band member played drums and percussion from 1992-2002 and you enter this as one AR, the db is parsing this to 2 relationships one for drums and one for percussion.

      Example here:
      http://musicbrainz.org/artist/5f58803e-8c4c-478e-8b51-477f38483ede/relationships

          [MBS-7676] When band member credited with multiple instruments, db creates multiple relationships, one for each instrument, instead of just one relationship for all the instruments

          Robert Kaye added a comment -

          We just discussed this ticket in the dev meeting:

          http://chatlogs.musicbrainz.org/musicbrainz-devel/2014/2014-06/2014-06-23.html#T19-19-00-944659

          And we feel that this ticket isn't clear and/or is conflating issues. If you can succinctly state an issue related to this ticket, please open a new ticket. Please DO NOT RE-OPEN this ticket.

          Thanks!

          Robert Kaye added a comment - We just discussed this ticket in the dev meeting: http://chatlogs.musicbrainz.org/musicbrainz-devel/2014/2014-06/2014-06-23.html#T19-19-00-944659 And we feel that this ticket isn't clear and/or is conflating issues. If you can succinctly state an issue related to this ticket, please open a new ticket. Please DO NOT RE-OPEN this ticket. Thanks!

          dr saunders added a comment -

          "How so? As you yourself noticed, you can still make your edit with multiple instrument attributes in the exact same way as before. When the edit is submitted, the server takes care to split the relationship automatically. So I don't see how this can be more work than before."

          Most membership edits required now are not simply adding all the members, usually you will have some or all members and sometimes some durations, so you are looking in some cases to add an aritst, some cases to add founder, some cases to add duration, some cases to add instruments, some cases to add 2 of those 4 items, sometimes its 3 and sometimes its all 4

          I agree editing has become quicker and easier for new editors and editors doing basic editing, but it sure isn't the case for advanced editing. I'm also sure that i'm "aware of all the tools" available to me for editing, I have contributed more data to this database than anyone else.

          "I'm not sure I understand here. Your description is not completely clear, but it sounds like editing an artist credit (e.g. if there are a number of releases/tracks/whatever using the artist credit "John A. Doe" and some others of the same artist using the artist credit "John B. Doe", but they are actually different persons, you could change all "John B. Doe"s to be a different artist). But that feature hasn't been removed or touched at all, nor anything related that I am aware of."

          Let's say we have 1 page in our db for "John B. Doe" but it is in fact 4 different people (this is actually a common occurence", in the old database you could start moving artist credits from the John B. Doe artist page to the new artists with the same name. Now you can't do that...for each individual credit you must go to the recording or release page and do the editing there. Trust me when I say that these exercises now take 4-5 times as long as they used to. Most people won't care or won't say anything about this as most people won't bother with artist disambiguation as its too complex or time consuming.

          "That's unnecessary work, really. When the site has had a hiccough, just click reload on the error page (you may have to confirm to the browser that you really want to re-post). Nothing will be lost"

          Oh how I wish that were true, however I know from experience that it is not.

          dr saunders added a comment - "How so? As you yourself noticed, you can still make your edit with multiple instrument attributes in the exact same way as before. When the edit is submitted, the server takes care to split the relationship automatically. So I don't see how this can be more work than before." Most membership edits required now are not simply adding all the members, usually you will have some or all members and sometimes some durations, so you are looking in some cases to add an aritst, some cases to add founder, some cases to add duration, some cases to add instruments, some cases to add 2 of those 4 items, sometimes its 3 and sometimes its all 4 I agree editing has become quicker and easier for new editors and editors doing basic editing, but it sure isn't the case for advanced editing. I'm also sure that i'm "aware of all the tools" available to me for editing, I have contributed more data to this database than anyone else. "I'm not sure I understand here. Your description is not completely clear, but it sounds like editing an artist credit (e.g. if there are a number of releases/tracks/whatever using the artist credit "John A. Doe" and some others of the same artist using the artist credit "John B. Doe", but they are actually different persons, you could change all "John B. Doe"s to be a different artist). But that feature hasn't been removed or touched at all, nor anything related that I am aware of." Let's say we have 1 page in our db for "John B. Doe" but it is in fact 4 different people (this is actually a common occurence", in the old database you could start moving artist credits from the John B. Doe artist page to the new artists with the same name. Now you can't do that...for each individual credit you must go to the recording or release page and do the editing there. Trust me when I say that these exercises now take 4-5 times as long as they used to. Most people won't care or won't say anything about this as most people won't bother with artist disambiguation as its too complex or time consuming. "That's unnecessary work, really. When the site has had a hiccough, just click reload on the error page (you may have to confirm to the browser that you really want to re-post). Nothing will be lost" Oh how I wish that were true, however I know from experience that it is not.

          Ulrich Klauer added a comment -

          Well then, reopened (and put into state "decision required").

          The display issue is obvious. or at least it seems obvious to me, I think if you put it to a vote I would be surprised if less than 8 in 10 users of the website didn't prefer the old method.

          This is completely non-controversial and was always planned, you can find it already mentioned in the comments on MBS-1377.

          As to the editing issue, now there is usually 2 or 3 times as many "entries" when editing and it is a lot more confusing and time consuming to add the membership information.

          How so? As you yourself noticed, you can still make your edit with multiple instrument attributes in the exact same way as before. When the edit is submitted, the server takes care to split the relationship automatically. So I don't see how this can be more work than before.

          as an aside I am very angry with the current trend to make advanced editing much harder and more time consuming than it was before, ...

          Actually, the objective is the opposite, and I think it is achieved, in general. The grand plan is to have fewer page loads by combining edit pages. E.g., previously, when you wanted to add a dozen relationships to an artist, you had to load an "add relationship" page, edit, submit, load another "add relationship" page, edit, submit, load ... Now you can add the dozen on one page and submit in one go.

          For the case where you really only want to add one thing as opposed to a dozen, it may be slightly slower because the one page load is heavier. However, developer time is limited as well, and when there are two separate ways to do something, that's two places that may have bugs, be out of sync with each other, etc.; so continuing to support "the old way" has quite a cost, too.

          I often have the feeling that people who complain about new obstacles to editing may not be using the best tools. There may be a shortcut or a feature that would save them a lot of time, but that they aren't aware of. An excellent example: A few days ago, an editor (from the "top editors" list) complained on IRC in passing about how difficult it was to add a relationship to a certain entity that wasn't easy to search for in the relationship dialog, and how much easier it had been before the "Use in a relationship" link was removed, etc. And someone asked, You know that you can just paste the URL for that entity into the dialog, don't you? - Well, that was that problem solved; and I bet using "Use in a relationship" had been much slower.

          However, solving workflow problems like that would require that people ask on IRC or in the forums, "I'm doing lots of such-and-such editing in such-and-such a way, and it's unwieldy and tedious, is there perhaps an easier and faster way to do this?" Then either they could be shown an easier way, via a userscript perhaps, or people could start thinking about improvements to the editing interface. But that doesn't happen often enough. Instead, tickets pop up saying "Your new feature is a bug! It's horrible! It must be undone immediately!" (e.g., MBS-7501, MBS-7564, this one), which generally isn't the type of message that is well received.


          Regarding the other things you mentioned:

          ... this is one bad example, artist disambiguation is even worse, where you used to be able to split out an artists' credits from that artist's page instead of having to go to each individual release or recording to fix, an effort that at least triples the time taken to fix artist disambiguation

          I'm not sure I understand here. Your description is not completely clear, but it sounds like editing an artist credit (e.g. if there are a number of releases/tracks/whatever using the artist credit "John A. Doe" and some others of the same artist using the artist credit "John B. Doe", but they are actually different persons, you could change all "John B. Doe"s to be a different artist). But that feature hasn't been removed or touched at all, nor anything related that I am aware of.

          Anyone who enters membership information at least semi-regularly will save their progress after a half-dozen ARs (I wish it wasn't so but the site is unreliable enough that just one 504 after a few hours of work will drive someone crazy and they will never again do a big project like that without saving progress a half-dozen ARs at a time).

          That's unnecessary work, really. When the site has had a hiccough, just click reload on the error page (you may have to confirm to the browser that you really want to re-post). Nothing will be lost.

          Ulrich Klauer added a comment - Well then, reopened (and put into state "decision required"). The display issue is obvious. or at least it seems obvious to me, I think if you put it to a vote I would be surprised if less than 8 in 10 users of the website didn't prefer the old method. This is completely non-controversial and was always planned, you can find it already mentioned in the comments on MBS-1377 . As to the editing issue, now there is usually 2 or 3 times as many "entries" when editing and it is a lot more confusing and time consuming to add the membership information. How so? As you yourself noticed, you can still make your edit with multiple instrument attributes in the exact same way as before. When the edit is submitted, the server takes care to split the relationship automatically. So I don't see how this can be more work than before. as an aside I am very angry with the current trend to make advanced editing much harder and more time consuming than it was before, ... Actually, the objective is the opposite, and I think it is achieved, in general. The grand plan is to have fewer page loads by combining edit pages. E.g., previously, when you wanted to add a dozen relationships to an artist, you had to load an "add relationship" page, edit, submit, load another "add relationship" page, edit, submit, load ... Now you can add the dozen on one page and submit in one go. For the case where you really only want to add one thing as opposed to a dozen, it may be slightly slower because the one page load is heavier. However, developer time is limited as well, and when there are two separate ways to do something, that's two places that may have bugs, be out of sync with each other, etc.; so continuing to support "the old way" has quite a cost, too. I often have the feeling that people who complain about new obstacles to editing may not be using the best tools. There may be a shortcut or a feature that would save them a lot of time, but that they aren't aware of. An excellent example: A few days ago, an editor (from the "top editors" list) complained on IRC in passing about how difficult it was to add a relationship to a certain entity that wasn't easy to search for in the relationship dialog, and how much easier it had been before the "Use in a relationship" link was removed, etc. And someone asked, You know that you can just paste the URL for that entity into the dialog, don't you? - Well, that was that problem solved; and I bet using "Use in a relationship" had been much slower. However, solving workflow problems like that would require that people ask on IRC or in the forums, "I'm doing lots of such-and-such editing in such-and-such a way, and it's unwieldy and tedious, is there perhaps an easier and faster way to do this?" Then either they could be shown an easier way, via a userscript perhaps, or people could start thinking about improvements to the editing interface. But that doesn't happen often enough. Instead, tickets pop up saying "Your new feature is a bug! It's horrible! It must be undone immediately!" (e.g., MBS-7501 , MBS-7564 , this one), which generally isn't the type of message that is well received. Regarding the other things you mentioned: ... this is one bad example, artist disambiguation is even worse, where you used to be able to split out an artists' credits from that artist's page instead of having to go to each individual release or recording to fix, an effort that at least triples the time taken to fix artist disambiguation I'm not sure I understand here. Your description is not completely clear, but it sounds like editing an artist credit (e.g. if there are a number of releases/tracks/whatever using the artist credit "John A. Doe" and some others of the same artist using the artist credit "John B. Doe", but they are actually different persons, you could change all "John B. Doe"s to be a different artist). But that feature hasn't been removed or touched at all, nor anything related that I am aware of. Anyone who enters membership information at least semi-regularly will save their progress after a half-dozen ARs (I wish it wasn't so but the site is unreliable enough that just one 504 after a few hours of work will drive someone crazy and they will never again do a big project like that without saving progress a half-dozen ARs at a time). That's unnecessary work, really. When the site has had a hiccough, just click reload on the error page (you may have to confirm to the browser that you really want to re-post). Nothing will be lost.

          dr saunders added a comment -

          My issue is both a display and an editing issue.

          The display issue is obvious. or at least it seems obvious to me, I think if you put it to a vote I would be surprised if less than 8 in 10 users of the website didn't prefer the old method.

          As to the editing issue, now there is usually 2 or 3 times as many "entries" when editing and it is a lot more confusing and time consuming to add the membership information.

          Anyone who enters membership information at least semi-regularly will save their progress after a half-dozen ARs (I wish it wasn't so but the site is unreliable enough that just one 504 after a few hours of work will drive someone crazy and they will never again do a big project like that without saving progress a half-dozen ARs at a time).

          So not editing these memberships are now hella confusing and a lot harder, and what do happens when you can actually get the multiple roles on the same line if you edit twice and remove the duplicates (My Barson example above).

          So because it causes removal edits to fix and should one day be easier to do these edits is why I won't be doing these anymore.

          (as an aside I am very angry with the current trend to make advanced editing much harder and more time consuming than it was before, this is one bad example, artist disambiguation is even worse, where you used to be able to split out an artists' credits from that artist's page instead of having to go to each individual release or recording to fix, an effort that at least triples the time taken to fix artist disambiguation)

          Please re-open the ticket. I don't think its fair that my opinions are summarily dismissed.

          dr saunders added a comment - My issue is both a display and an editing issue. The display issue is obvious. or at least it seems obvious to me, I think if you put it to a vote I would be surprised if less than 8 in 10 users of the website didn't prefer the old method. As to the editing issue, now there is usually 2 or 3 times as many "entries" when editing and it is a lot more confusing and time consuming to add the membership information. Anyone who enters membership information at least semi-regularly will save their progress after a half-dozen ARs (I wish it wasn't so but the site is unreliable enough that just one 504 after a few hours of work will drive someone crazy and they will never again do a big project like that without saving progress a half-dozen ARs at a time). So not editing these memberships are now hella confusing and a lot harder, and what do happens when you can actually get the multiple roles on the same line if you edit twice and remove the duplicates (My Barson example above). So because it causes removal edits to fix and should one day be easier to do these edits is why I won't be doing these anymore. (as an aside I am very angry with the current trend to make advanced editing much harder and more time consuming than it was before, this is one bad example, artist disambiguation is even worse, where you used to be able to split out an artists' credits from that artist's page instead of having to go to each individual release or recording to fix, an effort that at least triples the time taken to fix artist disambiguation) Please re-open the ticket. I don't think its fair that my opinions are summarily dismissed.

          Ulrich Klauer added a comment -

          I made MBS-7678 for the display issue.

          Ulrich Klauer added a comment - I made MBS-7678 for the display issue.

          Ulrich Klauer added a comment -

          Well, that's the display issue. Anything horrible about storing the relationships separately?

          Ulrich Klauer added a comment - Well, that's the display issue. Anything horrible about storing the relationships separately?

          yindesu added a comment -

          It's horrible because very few (if any) people want to see instrument-person pair memberships of a group - they want to see a person once.

          yindesu added a comment - It's horrible because very few (if any ) people want to see instrument-person pair memberships of a group - they want to see a person once.

          Ulrich Klauer added a comment -

          reosarevok: Repurposing a ticket like that is just confusing (unless you delete the comments that no longer have anything to do with the new state, but even then, there is the history). It's already unclear whether the votes (2 currently) are for "undo MBS-1377" or "improve the display". Make a different ticket for a different issue.

          drsaunders: Please explain why this is "horrible" and "stops you from entering membership roles for groups".

          Ulrich Klauer added a comment - reosarevok: Repurposing a ticket like that is just confusing (unless you delete the comments that no longer have anything to do with the new state, but even then, there is the history). It's already unclear whether the votes (2 currently) are for "undo MBS-1377 " or "improve the display". Make a different ticket for a different issue. drsaunders: Please explain why this is "horrible" and "stops you from entering membership roles for groups".

          dr saunders added a comment -

          If this is intentional, it should pass some kind of style vote or something because this is horrible

          In fact it's going to stop me from entering membership roles for groups, and considering i'm one of the few that takes the time to do this, I would say its significant.

          oh and it's not like it even works like that, see my example above for Mike Barson from 1992-present there's the individual relationships and there's a combined one too

          dr saunders added a comment - If this is intentional, it should pass some kind of style vote or something because this is horrible In fact it's going to stop me from entering membership roles for groups, and considering i'm one of the few that takes the time to do this, I would say its significant. oh and it's not like it even works like that, see my example above for Mike Barson from 1992-present there's the individual relationships and there's a combined one too

          Reopening because even though storing them like that is intentional, the current display is just terrible and needs fixing. The ticket might need to be reworded a bit, but still.

          Nicolás Tamargo added a comment - Reopening because even though storing them like that is intentional, the current display is just terrible and needs fixing. The ticket might need to be reworded a bit, but still.

            Unassigned Unassigned
            drsaunde dr saunders
            Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package