Moving OBJ above derivatives.

[whikloj]

Partially addresses ISLANDORA-1527

What does this Pull Request do?

Re-order datastreams to allow proper derivative creation when batch ingesting large images

How should this be tested?

Batch ingest one or more large images using drush (islandora_batch_scan_preprocess).
Before the derivatives (TN, JP2) files were not generated after ingest.
Now they should be generated once the objects are ingested.

[whikloj]

@nhart If you want to have a look to make sure I'm doing this correctly. 😄

[ruebot]

@whikloj looks like we need to resolve merge conflicts.

Once that is done, @nhart, are you still willing to review and merge this?

[ruebot]

@nhart bump

@whikloj looks like we have merge conflicts 😢

[whikloj]

Rebased and ready to go.

[nhart]

I didn't test this, did you @ruebot? Don't see anything mentioned in the pr comments or ticket about testing results.

[adam-vessey]

(Just updating an environment, and checking out the changes...)

Also, looks like this might be effecting/undoing one of @rosiel's changes, since it no longer has the optional flag.

[ruebot]

Shall we revert? Or should we put in an updated pull request?

[ruebot]

...that said, I'm happy to put in a quick pull request since I merged this one.

[adam-vessey]

Somewhat ambivalent, am I... I'm not sure it should be there (or if present, should be optional="false")... Should the DS-COMPOSITE-MODEL document the final, fully-populated state of the object, or any (or all?) states of the object?

[ruebot]

So we're consistent with the other solution packs, we should have optional="true" in there, and I'll own it and take the blame for not catching that when I merged. I should have known better since I tested and merged most of @rosiel's work around making OBJ datastreams optional.

So, I'll do a quick pull request to add optional="true" to this to fix it, and just associated it with this pull request and existing JIRA ticket.

[rosiel]

Thanks for catching this!

@adam-vessey I agree with you. I'm not sure about the philosophical meaning of the DS_COMPOSITE_MODEL but it was suggested to change this when making the upload optional in the ingest forms. Previously we've only made optional any derivative datastream that system could create (or not) while the payload was always OBJ and it was assumed that this was the preservation target.

Are there use cases where a final, fully populated object would not have an OBJ (when it is of one of these standard solution pack content models)? Perhaps we should discuss this on the message board. Until this is resolved, thanks for maintaining consistency.

[whikloj]

Thanks all, that was my mistake after the rebase of this PR on recent changes.