• Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: Fedora 3.6, Fedora 3.6.1, Fedora 3.6.2
    • Fix Version/s: Fedora 3.7.1
    • Component/s: legacy - Fedora
    • Labels:
    • Roadmap Theme:


      Legacy storage:
      INGEST: foo:1 201310091500000
      1) DOManager checks the pidRegistry Db for foo:1
      2) if no, creates

      Akubra storage:
      INGEST: foo:1 201310091500000
      1) ditto
      2) if no, MD5 “info:fedora/foo:1”
      3) build directory structure from hash advantage: you don’t have to look up path in Db
      Scenario: As of 20131010, Db is corrupt, or not up to date, or incomplete, or maybe the last val for PIDs in namespace just reset
      INGEST: foo:1 201310101500000
      1) DOManager checks the pidRegistry Db for foo:1
      2) if no, creates {OBJECTS}

      Where are you now? Original foo:1 is orphaned, but exists, as do datastreams
      Everything that has the same id gets overwritten irreperably
      Circumstances that this happens in:
      1) pidRegistry is jacked
      AND 2) you use sequential pids (as opposed to random, or UUIDs) AND 3) you use Akubra (Legacy you just have orphan objects)
      What can we do?
      1) Legacy, we can build a report of duplicates, and possibly provide a FCSU command to move them to a unique PID
      2) Akubra, we can really just tell you that an objectCreation date is out­of­sequence with it’s PID (this is crappy)
      Is this behavior on ingest in the context of a bad Db fixable?
      1) Legacy: not really. To do this without the Db, you would have trawl the corpus of FOXML, which would not only be slow, but the would be maximally slow
      on the non­error requests (ie, a new PID). Non­starter.
      2) Akubra: Yes, because the DOManager could be required to ping an Akubra objectstore as part of the objectExists() call. Raise an exception.




            • Assignee:
              barmintor Benjamin Armintor
              eddie Edwin Shin
            • Votes:
              0 Vote for this issue
              3 Start watching this issue


              • Created: