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

When adding a Bitstream to a Bundle, the 'bitstream_order' is always set to the 'sequence_id'

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.8.0, 1.8.1
    • Fix Version/s: 1.8.2
    • Component/s: DSpace API
    • Labels:
      None
    • Attachments:
      3
    • Comments:
      10
    • Documentation Status:
      Not Required

      Description

      Currently, in the Bundle.addBitstream() method the 'bitstream_order' setting is always set to the same value as the 'sequence_id'.
      This makes a large assumption that these two fields should always be equal for newly created bitstreams.

      However, in scenarios where you are restoring an Item and its Bitstreams (like via AIP Backup & Restore), this assumption falls flat. In 'restore' scenarios, it's very possible you may want to restore the 'sequence_id' as 2 while the 'bitstream_order' should be 1. Unfortunately, this becomes problematic, as the 'addBitstream()' method will always assume bitstream_order=sequence_id.

      My proposal is to instead implement Bundle.addBitstream() so that it is always appending the newly added bitstream to the end of the current list of Bitstreams. So, instead it should set:
      bitstream_order = bitstreams.size()

      This will work fine for 'restore' scenarios, as Bitstreams are always restored in order, so the bitstream_order may be restored to a different value to the sequence_id.

      A proposed patch to the Bundle class is attached. I've done some minimal testing so far, but it seems stable. I have verified that with this patch in place, I can now restore both an Item's bitstream_order and sequence_id to different values (as necessary), via the AIP Backup & Restore tools.

      I'd appreciate feedback on this approach.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: