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

Don't return unrelated recording-work relationships within work-level-rels from /ws/2/release

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2020-10-05
    • None
    • Web service
    • None

      A request like https://musicbrainz.org/ws/2/release/8e061dc4-790e-4587-ba53-011e7852f88d?inc=release-groups+media+recordings+puids+artist-credits+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels should not contain work-level relationships back to other recordings, because these recordings are either not on this release or this relationship is already returned for the related tracks.

      Per a comment by @voiceinsideyou on MBS-3122:

      With analysis, ~1172 / 1223Kb (95.8%) of the XML data is work level ARs back to /other/ recordings - it's 50kB without these. Pretty sure the numbers are correct; I manually went through the XML and cut out these blocks. Nirvana is especially bad, probably due to the live bootlegs project, and likely a large number of unmerged recordings, however I'm not sure whether Picard uses these back-references, but given the impact they have - perhaps there needs to be a way to filter these work <- has performance of -> recording ARs out, but still get composer ARs and the like?

      While I didn't perform a new analysis, I'm guessing this is still accurate. The response size of the same request has ballooned to 2.82 MB since that comment was made in 2011, and there are still tons and tons of these unneeded relationships in the output.

            reosarevok Nicolás Tamargo
            bitmap Michael Wiencek
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package
                2020-10-05