Primary bitstream

[benbosman]

Fixes https://github.com/DSpace/dspace-angular/issues/1578 REST Implementation: https://github.com/DSpace/DSpace/pull/8876

[hardyoyo]

I'm wondering if this change to the REST Contract would facilitate a use case where one needed to toggle a "primary bitstream" designation at the time of submission, or if this endpoint is only valid for bitstreams on already in-archive items?

[abollini]

@hardyoyo as anticipated yesterday during the dev meeting to manipulate the primary bitstream during the submission a different approach would be needed so this should be leave out-of-scope of this PR. The submission requires that all the aspects are driven in the "sections", so I expect changes here https://github.com/DSpace/RestContract/blob/main/workspaceitem-data-upload.md

[mwoodiupui]

Executive summary: I don't disagree with the changes which have been requested. But, having studied the problem a bit, I feel compelled to say why.

If I may muddy the waters a bit: a look at the Bundle table's header shows that the identity of the primary bitstream is precisely a property of the bundle. I would not agree that "primary bitstream" is a relationship; primacy is an attribute of the Bundle2Bitstream relationship, and perhaps should have been stored there. (isPrimary BOOLEAN)

But these are storage layer details that the business logic should neither know nor care about. So far as the business logic is concerned, a Bundle can have one Bitstream which is "primary", whatever that means, w.r.t. that Bundle. So singling out the primary Bitstream with a special path seems the right way to go, because having the REST layer model the storage layer would be pointless complexity and push into the client work which belongs at the server.

The confusion arises because the primary Bitstream is also one of the plain Bitstreams, not some other kind of Bitstream which is stored separately. Any solution will seem forced.

[tdonohue]

@mwoodiupui : While that's all correct, I think that's precisely why this contract is most similar to the "owning collection" concept. The OwningCollection is "technically" (at the database level) a column in the item table. It's also one collection of potentially many that the Item is "linked" to.

This is why I think these two endpoints should be designed in the same way, as they are somewhat similar conceptually. Conceptually they are an object-to-object relationship that has been singled out as special, regardless of how they are stored at the database level.

[benbosman]

I've reviewed your feedback, and we can indeed adjust the contract. I've modified it now

It's also correct that this is only for archived items. The submission will be dealt with in the future

[benbosman]

Thanks for the feedback @abollini , I've added the status codes