-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Cannot retrieve any type of identifier from the files created with uploadFile
method since it does not return any information of the created file
#16
Comments
The workaround we use in tests is to retrieve the SWORD statement using a method called getFileIdFromSwordStatementBody: https://github.com/IQSS/dataverse/blob/v5.12.1/src/test/java/edu/harvard/iq/dataverse/api/UtilIT.java#L1003 That is to say, from what I can tell, no, with SWORD we don't give you the database ID of the file in the deposit receipt. You have to make a separate call to the get the statement. Yes, this is pretty sub-optimal. The native (JSON) API works in a more sane manner, returning the database ID of the file when you upload the file. For reference, this is what I'm seeing as output when you upload a file via SWORD (no "database ID 7" or whatever):
|
Hi, I'm working on supporting native API file upload, will do a PR soon. I don't think this was available last time I looked which was a while ago. |
PR #23 contains a fix for this if anyone wants to take a look. |
closing, assumed done |
When using the
uploadFile
method, it uses internally the methoddeposit
from classUploadFile
. Method deposit returns aDepositReceipt
that contains the result of the operation, for example the identifier of the file that you uploaded, but the methoduploadFile
does not return anything. This makes impossible to keep manipulating the file for example for metadata addition because you are not returning the identification.¿Could you please explain if this is the intentional design? ¿Is there a possible workaround to obtain the id of the file that you updated with the
uploadFile
method?If not I will raise another pull request to fix this or add another method that has this behaviour.
The text was updated successfully, but these errors were encountered: