Change Details

This almost keeps the revision metadata format as is. It sends the raw metadata (xml instead of the parsed json before). Questions: - do we keep the raw metadata attached to the revision as it's currently done? -> currently the deposit server writes the raw metadata to the directory (during an update D4013), not on the revision as it cannot. -> if we need to change it (attach the raw extrinsic metadata to the directory in the metadata storage), that's doable. It's a more involved refactoring though as the package loader does not allow it yet. And this can be done as a next diff. - revision: do we send one raw extrinsic metadata column per raw xml received (the deposit allows this) or one joined xml (that's the current taken approach which match the task). Let's discuss ^ Related to T2649 Related to D4100 Related to D4101

Note that still writes the metadata to the revision. Format wise, this almost keeps those revision metadata format as it is. It sends the raw metadata xml instead of the parsed json it used to. It cannot write in json any longer as it got removed in D4100. Questions: - (storage metadata) Do we keep the raw metadata attached to the revision as it's currently done or do we attach it to the directory instead or both? -> currently the deposit server writes the raw metadata to the directory (during an update D4013), not on the revision as it cannot. -> if we need to change it (attach the raw extrinsic metadata to the directory in the metadata storage), that's doable. It's a more involved refactoring though as the package loader does not allow it yet. And this can be done as a next diff. - (storage) Do we keep writing the metadata to the revision at all (we could stop now that the loaders are writing to the metadata storage)? Remark: Implementation wise, this sends one raw extrinsic metadata column per raw xml received (a deposit can be done in multiple requests, which translates into multiple raw xml files). The first implementation of this was to join all xml into one concatenated xml. As this meant more handling down the line, when reading, this was changed into this instead. Related to T2649 Related to D4100 Related to D4101

TNote that still writes the metadata to the revision. Format wise, this almost keeps theose revision metadata format as it is. It sends the raw metadata (xml instead of the parsed json before)it used to. It cannot write in json any longer as it got removed in D4100. Questions: - do- (storage metadata) Do we keep the raw metadata attached to the revision as it's currently done or do we attach it to the directory instead or both? -> currently the deposit server writes the raw metadata to the directory (during an update D4013), not on the revision as it cannot. -> if we need to change it (attach the raw extrinsic metadata to the directory in the metadata storage), that's doable. It's a more involved refactoring though as the package loader does not allow it yet. And this can be done as a next diff. - revision: do we send one raw extrinsic metadata column per raw xml received (the deposit allows this) or one joined xml (that's the current taken approach which match the task).(storage) Do we keep writing the metadata to the revision at all (we could stop now that the loaders are writing to the metadata storage)? Let's discuss ^Remark: Implementation wise, this sends one raw extrinsic metadata column per raw xml received (a deposit can be done in multiple requests, which translates into multiple raw xml files). The first implementation of this was to join all xml into one concatenated xml. As this meant more handling down the line, when reading, this was changed into this instead. Related to T2649 Related to D4100 Related to D4101