Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-2166

DSpace 5.0 Upgrade process is broken (related to Metadata 4 All)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 5.0
    • Fix Version/s: 5.0
    • Component/s: DSpace API
    • Labels:
      None
    • Attachments:
      0
    • Comments:
      3
    • Documentation Status:
      Not Required

      Description

      When upgrading an existing Database to the latest master (after the addition of Metadata 4 All, DS-2164), you don't end up with a completely usable database.

      The underlying problem is that the new metadata registries (e.g. EPerson) are not loaded automatically during the upgrade, as "ant update" does NOT call "load_registries". (UPDATE: I'm wrong, it calls "update_registries" instead – see below)

      This is further complicated by the fact that the 4->5 Database upgrade SQL requires that those new metadata_fields exist, e.g.

      https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/database_schema_4_5.sql#L255

      Notice that there's a SELECT statement to attempt to determine the proper value of "metadata_field_id" for the migrated data. Unfortunately, if you don't have those new metadata registries, this SELECT will always return "null"...which results in a corrupted database (even though your metadata values still exist, they are no longer mapped to metadata fields).

      To sum up, the upgrade process from DSpace 4 -> 5 needs to ensure that the new metadata schema registries are created BEFORE the database upgrade script is actually run. Otherwise you end up with an invalid database.

      UPDATE: realized that "ant update" actually calls "update_registries" (a new target) to load these registries (and I had an old copy of the Ant build script cached). But, this corrupted database still can occur if you accidentally run the DB upgrade prior to running "ant update". It could be that we just have a very explicit WARNING in the upgrade documentation to this effect.... if we cannot find a better way to avoid this DB corruption.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                tdonohue Tim Donohue
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: