On 10/27/2011 8:52 AM, Mark H. Wood wrote: >> 2.) The uniqueness constraint and the sequence_id should be expressed >> in the database, such constraints shouldn't be bound in application >> code, this is an example of poor design choices on where to persist >> this detail, it should not have been stored on the bitstream table, it >> should have been in the bundle2bitstream table, or if you want it >> unique across all bitstreams in an item, there should have been a >> item2bitstream table that stored the sequence id, then the uniqueness >> constraint could have been enforced properly. >> Why, because sequence id is irrelevant to the Bitstream itself, it is >> an attribute of the container/collection object that is aggregating >> the bitstreams. A sequence id is meaningless in relation to the >> Bitstreams that are used in Community and Collection logos, etc. It is >> only relevant to the Item/Bundle container holding the Bitstream. > > That's what I thought until I read Richard Rodgers' note on the > design. If sequence_id *were* used for sequencing things, then it > would properly be an attribute of the relationship between the > bitstream and the thing within which it is sequenced, not of either > object. > > But that's not what it's supposed to be for; it's a stable identifier > for the bitstream, unique within item but otherwise meaningless. It > should've been called something like name or serial_no to indicate > that it is uninterpretable.
I believe MarkW is correct here. I think 'sequence_id' was badly named initially. It's not really a "sequence". Rather, as RichardR's note mentions, it's actually more of an identifier (which is why it was used in the JSPUI as the identifier for the bitstream you want to view within an item). It was never actually used to order/sequence bitstreams in an item or bundle. So, in the longer term, it probably would be more appropriate to make this a global identifier (rather than just a unique identifier in an Item). So, replacing sequence_id with a Bitstream handle (or other form of global identifier) may be the best route in the long term. In any case, I agree there is bunch of messiness in our data model that probably needs to be cleaned up. Longer term, I'd also be fine with doing away with bundles, as they don't really give us much. If we still want the "grouping" functionality that bundles provide, that could still be achieved via a "group" attribute on a bitstream (or something similar). In the short term, I also agree with MarkW that it might be good to go ahead and plug up this DBMS hole with a more accurate uniqueness check. Longer term, hopefully assigning handles or other external identifiers to bitstreams can make the 'sequence_id' obsolete. - Tim ------------------------------------------------------------------------------ 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
