Hi Mark, My answer would be that bitstream 'sequence_id' should be unique *per-Item*. Admittedly though, this doesn't seem to be documented anywhere.
The reason why I think it is *per-Item* is based on how it is implemented in our code/database. There is only one 'sequence_id' per 'bitstream' (it's a column in the 'bitstream' table). But, as you noted, a bitstream may be linked into one or more bundles. At least the data model supports this idea of a bitstream in multiple bundles (even though I'm not sure if there's actually a way to map to multiple bundles from the UI or CLI). So, currently, based on the data model, it'd be impossible for a single bitstream to have different 'sequence_id' values for different Bundles (for that to work, the 'sequence_id' would need to be on the 'bundle2bitstream' table instead of the 'bitstream' table). All this being said, it makes me wonder how you ended up with an item that has two bitstreams with the same 'sequence_id'. Looking at the code in Item.update(), it looks like this should not be "possible", as the code which assigns 'sequence_id' always attempts to assign the next largest value. Surprisingly, I don't see any other code in our DSpace API that even calls "bistream.setSequenceID()" Obviously, somehow your data still managed to end up with the same sequence_id though. :) I'm just not sure how. - Tim On 10/26/2011 12:15 PM, Mark H. Wood wrote: > Hmmm, where *is* the sequence_id defined and discussed, anyway? > > It appears that the sequence_id must be (expected to be) unique > per-item, because a bitstream can be in more than one bundle > (Bitstream.getBundles returns an array) and that makes nonsense of > having a single sequence_id if it's per-bundle. > > Hmmm, grepping around for sequence_id finds a comment in the class > which upgrades DSpace 1.1 to 1.2, which comment leads me to > Item.update(). There any unsequenced bitstreams are indiscriminately > given serially-numbered sequence_ids higher than any found in the > item. Again this is suggestive but not definitive. However it also > destroys any speculation that sequence_id might be used to relate > derivative bitstreams to source bitstreams. (Can you see I'm grasping > at straws to explain our data?) > > I'm rattling on like this because (a) I'm hoping that someone who > knows the design can confirm or deny my deductions; and (b) this > should be documented somehow, and the record of my investigations may > help in that effort. > > > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > > > > _______________________________________________ > Dspace-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
