Refactor ISRC and ISWC tables to have one entry per ISRC/ISWC

XMLWordPrintable

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Normal
    • None
    • Affects Version/s: None
    • Component/s: Schema Change
    • None

      Currently our ISWC and ISRC tables store ISWC-work and ISRC-recording pairs, respectively. This means that even though we have pages such as https://musicbrainz.org/isrc/USSM19932777 (that can list multiple codes), there isn't one DB row nor one DB id for this ISRC.

      This is blocking MBS-7406 and would in general make our DB structure match the way we actually think about and use the codes.

      We should move the work and recording association out of the ISRC and ISWC tables, and onto their own iswc_work and isrc_recording tables.

      It would probably involve something like moving from:

      CREATE TABLE isrc ( -- replicate (verbose)
          id                  SERIAL,
          recording           INTEGER NOT NULL, -- references recording.id
          isrc                CHAR(12) NOT NULL CHECK (isrc ~ E'^[A-Z]{2}[A-Z0-9]{3}[0-9]{7}$'),
          source              SMALLINT,
          edits_pending       INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >= 0),
          created             TIMESTAMP WITH TIME ZONE DEFAULT NOW()
      );
      

      to the combination:

      CREATE TABLE isrc ( -- replicate (verbose)
          id                  SERIAL,
          isrc                CHAR(12) NOT NULL CHECK (isrc ~ E'^[A-Z]{2}[A-Z0-9]{3}[0-9]{7}$'),
          edits_pending       INTEGER NOT NULL DEFAULT 0 CHECK (edits_pending >= 0),
          last_updated             TIMESTAMP WITH TIME ZONE DEFAULT NOW()
      );
      
      CREATE TABLE isrc_recording ( -- replicate (verbose)
          isrc           INTEGER NOT NULL, -- PK, references isrc.id
          recording           INTEGER NOT NULL, -- PK, references recording.id
          last_updated             TIMESTAMP WITH TIME ZONE DEFAULT NOW()
      );
      

      Since both tables are mutable (one has edits_pending and the other will change on recording merges) last_updated seems more appropriate than created, so we change that (they could start by keeping the created date of the original table for the association, and the latest created date of any associations with a code for the code table). edits_pending seems best to keep on the code since the code is what we generally highlight if there are any pending edits even now.

            Assignee:
            Unassigned
            Reporter:
            Nicolás Tamargo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:

                Version Package