[
https://jira.duraspace.org/browse/DS-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24181#comment-24181
]
Kevin Van de Velde commented on DS-1122:
----------------------------------------
Discussion from the developer meeting on 15/02/2012:
kompewter: [ https://jira.duraspace.org/browse/DS-1122 ] - [#DS-1122] When
adding a Bitstream to a Bundle, the 'bitstream_order' is always set to
the 'sequence_id' - DuraSpace JIRA
[21:21] tdonohue: One related issue is that after a new Item Submission, all
bitstreams currently start out in a random order (they all are assigned
"bitstream_order=-1" by default)
[21:21] tdonohue: I had also emailed dspace-devel about this, but didn't get
any response. Not sure if anyone here knows how this should function, and
whether there is a bug here or not?
[21:22] tdonohue:
http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08375.html
[21:22] kompewter: [ [Dspace-devel] Bitstream ordering always initialized to
-1(unordered)? ] -
http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg08375.html
[21:22] KevinVdV: Well it is a bug the numbers of the bitstreams should always
be the ones in the order they have been added (for new ones that is)
[21:22] mdiggory: So you preserve Bitstream order in the AIP?
[21:23] tdonohue: nope, I currently cannot preserve bitstream order in the
AIPs. I'd like to preserve it, but currently it's impossible as any new Item
added to DSpace (via AIP or via Submission UI) always resets all bitstreams to
"order=-1"
[21:24] mdiggory: ordering was never a full feature in dspace.
[21:26] mdiggory: I'm trying to remember my past position on ordering being in
Bundle
[21:26] tdonohue: ok. maybe that's my confusion. I just don't know how this is
supposed to work. The current implementation though makes it impossible to
retain ordering in an AIP (In reality, AIPs already retain bitstream ordering,
it's just that DSpace cannot restore it)
[21:26] KevinVdV: The bitstream order should be set in the order the bitstreams
are added to the item
[21:26] mhwood: Isn't this one of those places where order was thought to be
insignificant, and then we heard from the user community that it most
definitely is significant?
[21:27] mdiggory: Order in the UI you mean
[21:27] mdiggory: speaking to mhwood
[21:27] mhwood: Yes, in the UI.
[21:28] tdonohue: I've found the underlying problem here...the underlying issue
is that "Bundle.addBitstream()" tries to set the proper order on a new
bitstream. But, unfortunately, it uses "sequence_id" to set the ordering, and
"sequence_id" is uninitialized (-1) until Item.update() gets called.
[21:28] mdiggory: Thus the question is, if ordering is an intrisic part of the
DSpace API itself, or just behavior on it
[21:28] mhwood: Anyway, you get different answers depending on whether you
think "how it's supposed to work" means "how was it designed" or "how is it
used?"
[21:29] mdiggory: ordering was a customization after the design.
[21:29] mdiggory: but... not to distract...
[21:30] mdiggory: tdonohue: sounds like we need a method that includes the
ability to pass the order?
[21:30] tdonohue: my understanding is that folks really wanted/like this
feature (like mhwood remembers). It also would make sense that if you do a
backup & restore (via AIPs or otherwise), you'd expect things to get restored
with bitstreams in the same ordering.
[21:30] tdonohue: mdiggory: yea, that might be a possible fix. I was wanting
feedback from others though, as I wasn't sure if I fully understood how this is
supposed to work (hence my questions)
[21:31] mdiggory: If order / position were a property of the Bitstream, then
you;d have something concrete to preserve and restore, reguardless of the logic
for things getting added to a bundle
[21:32] mdiggory: right now ordering is controlled in Bundle but based on
properties of bitstream
[21:32] mdiggory: String bitstreamOrderingField =
ConfigurationManager.getProperty("webui.bitstream.order.field");
[21:32] mdiggory: String bitstreamOrderingDirection =
ConfigurationManager.getProperty("webui.bitstream.order.direction");
[21:34] mdiggory: note these are fields in
[21:34] mdiggory: bitstream.*,bundle2bitstream.bitstream_order
[21:34] mdiggory: so ordering is derived from either the Bitstream fields or
the bundle2bitstream.bitstream_order field
[21:35] mdiggory: so this case is only in regards to when its set in
bundle2bitstream.bitstream_order
[21:35] tdonohue: right, mdiggory. And when you set:
'webui.bitstream.order.field=bistream_order', that's where the ordering is
always initialized to -1 for newly added bitstreams
[21:36] mhwood: I don't see why this is a concern of either Bitstream *or*
Bundle. It seems to me it belongs to Item.
[21:36] mdiggory: and thats because the sequence isn't producing until a commit
happens...
[21:36] tdonohue: mhwood: that's a good thought. That's exactly how
*sequence_id* is managed, at the item level
[21:38] tdonohue: which is what causes the oddity here. bitstream_order is
managed by Bundle, but it tries to initialize itself via the 'sequence_id'
which doesn't get initialized until the Item is updated
[21:39] mdiggory: that sequence_id comes from?
[21:39] mdiggory: bitstream_seq;
[21:39] mdiggory: or bundle2bitstream_seq;\
[21:40] tdonohue: sequence_id actually doesn't use a DB sequence. It just
locates the highest value in the Item and adds one
[21:40] mdiggory: bundle2bitstream_seq;
[21:40] tdonohue: so, this is all a mess, to be honest. It's just shown itself
in the fact that bitstream_order doesn't work as planned
[21:41] mdiggory: mappingRow.setColumn("bitstream_order", b.getSequenceID());
[21:41] mdiggory: comes from the bitstream_seq
[21:41] tdonohue: ??
[21:42] mdiggory: just clarifying that I understand now what you said earlier
[21:42] KevinVdV: Couldn't we just add a bitstream_order on bitstream add to
bundle & on each remove from bundle recalculate the order of the bitstreams ?
[21:43] tdonohue: KevinVdV -- I think so, it's just that in initializing
bitstream_order (in add to bundle), you couldn't use 'sequence_id' as it
doesn't get initialized until later.
[21:44] mdiggory:
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Bundle.java#L456
[21:44] kompewter: [ dspace-api/src/main/java/org/dspace/content/Bundle.java at
master from DSpace/DSpace - GitHub ] -
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Bundle.java#L456
[21:44] tdonohue: I'm wondering if it might make more sense to bring this
discussion over to dspace-devel or to JIRA ticket?
[21:44] KevinVdV: True but you could use bitstreams.size() or something like
that IF you recalculate it in removeBitstream each time it should be alright
[21:45] tdonohue: KevinVdV -- yes, that could work. Just not sure how expensive
it'd be to recalculate -- but maybe it wouldn't be that bad overall.
[21:46] KevinVdV: Well you would just have to recalculate on the bistreams
AFTER the current one
[21:46] KevinVdV: current one == the removed one
[21:46] tdonohue: In any case, KevinVdV do you want to bring this discussion
over to dspace-devel or to Ds-1122? Maybe we can brainstorm out a
resolution/fix along those lines.
[21:47] KevinVdV: I will add this discussion to the JIRA & add my own thoughts
below it
[21:47] mhwood: In case it's relevant, there was some discussion of the meaning
and use of sequence_id back on 25-Oct-2011: Message-ID:
<20111025175822.ga15...@iupui.edu>
> 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
