[ 
https://jira.duraspace.org/browse/DS-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24111#comment-24111
 ] 

Tim Donohue commented on DS-1122:
---------------------------------

I've noticed there's another oddity with how "bitstream_order" already works.  
If you create a brand new Bitstream in the system, it's sequence_id isn't set 
until Item.update() is called.  This means that the 'bitstream_order' doesn't 
get set properly at all.  

I just tried the following in the 1.8.1 XMLUI, and here's what happens:

* Create an Item that has two Bitstreams:
      - Bitstream A (bitstream_order: 1, sequenceID: 1)
      - Bitstream B (bitstream_order: 2, sequenceID: 2)
* Add a brand new Bitstream ('C') to this Item:
      - Bitstream C (bitstream_order: -1, sequenceID: 3)
* Add another new Bitstream ('D') to this Item:
      - Bitstream D (bitstream_order: -1, sequenceID: 4)

You'll notice the last two bitstreams end up with an order=-1, as the 
'bitstream_order' field gets set before the sequence_id is ever initialized.  
So, adding new Bitstreams in general causes a 'random' ordering of bitstreams 
(as they always get set to 'bitstream_order'=-1 by default, until someone goes 
in and manually reorders them)
      
                
> When adding a Bitstream to a Bundle, the 'bitstream_order' is always set to 
> the 'sequence_id'
> ---------------------------------------------------------------------------------------------
>
>                 Key: DS-1122
>                 URL: https://jira.duraspace.org/browse/DS-1122
>             Project: DSpace
>          Issue Type: Bug
>          Components: DSpace API
>    Affects Versions: 1.8.0, 1.8.1
>            Reporter: Tim Donohue
>            Assignee: Tim Donohue
>             Fix For: 1.8.2
>
>         Attachments: Bundle.patch
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to