This older discussion speaks to the same issue: http://sourceforge.net/mailarchive/message.php?msg_id=13272819.
>From the message: __________________________________________________ Here's a little more explanation/history of the sequence ID. First, it is assigned sequentially and IDs are not reused if a bitstream is deleted. There is no magic ordering, and it was *not* intended for organizing a set of bitstreams into a meaningful sequence (e.g. PDF chapters of a book). Its sole purpose is to provide a *durable* unique ID for a bitstream - think of it as a 'sub-handle' ID - modulo an item (sorry for the Latin again, it just kind of crept in). DSpace originally used the bitstream database key, but while unique, this wasn't durable in the sense that if you moved to a different database, or compressed, etc, the key might change. Whereas the sequence ID is a bona fide (damn!) piece of metadata, albeit a fairly opaque one. Remember that the filename need not be unique (you can have 2 bitstreams with the same name), so we do need something in this role. We actually kicked around various proposals (e.g. MD5 checksums, date stamps, etc), but the sequence ID won primarily because it resulted in shorter, easier-to-type URLS. Hope this sheds some light, Richard R __________________________________________________ B-- >>> On 10/26/2011 at 12:14 PM, in message <[email protected]>, Tim Donohue <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
